ipsec + mpd5 with windows 7/8 clients behind nat

Hello, I've got a racoon/mpd5 setup that works great with windows clients that is not behind nat. However if they are behind nat they can't connect.

On mac os x clients, it works fine even when they are behind nat. I've googled on this but all I seem to find is nat-t problems. I don't use any of that and my ipsec/mpd5 server has a public ip, I'll post my racoon.conf here.

The racoon log looks like its all gonna work but there is never any connection to mpd5, npd5 log shows nothing.

here is racoon log.
Code:
fjuttsi# racoon -v -F
Foreground mode.
2012-09-03 12:53:06: INFO: @(#)ipsec-tools 0.8.0 ([url]http://ipsec-tools.sourceforge.net[/url])
2012-09-03 12:53:06: INFO: @(#)This product linked OpenSSL 0.9.8q 2 Dec 2010 ([url]http://www.openssl.org/[/url])
2012-09-03 12:53:06: INFO: Reading configuration from "/usr/local/etc/racoon/racoon.conf"
2012-09-03 12:53:06: INFO: 85.244.244.244[4500] used for NAT-T
2012-09-03 12:53:06: INFO: 85.244.244.244[4500] used as isakmp port (fd=4)
2012-09-03 12:53:06: INFO: 85.244.244.244[500] used for NAT-T
2012-09-03 12:53:06: INFO: 85.244.244.244[500] used as isakmp port (fd=5)
2012-09-03 12:53:16: INFO: respond new phase 1 negotiation: 85.230.57.9[500]<=>2.71.199.147[500]
2012-09-03 12:53:16: INFO: begin Identity Protection mode.
2012-09-03 12:53:16: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
2012-09-03 12:53:16: INFO: received Vendor ID: RFC 3947
2012-09-03 12:53:16: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2012-09-03 12:53:16: INFO: received Vendor ID: FRAGMENTATION
2012-09-03 12:53:16: [2.71.199.147] INFO: Selected NAT-T version: RFC 3947
2012-09-03 12:53:16: ERROR: invalid DH group 20.
2012-09-03 12:53:16: ERROR: invalid DH group 19.
2012-09-03 12:53:17: [85.230.57.9] INFO: Hashing 85.230.57.9[500] with algo #2
2012-09-03 12:53:17: INFO: NAT-D payload #0 verified
2012-09-03 12:53:17: [2.71.199.147] INFO: Hashing 2.71.199.147[500] with algo #2
2012-09-03 12:53:17: INFO: NAT-D payload #1 doesn't match
2012-09-03 12:53:17: INFO: NAT detected: PEER
2012-09-03 12:53:17: [2.71.199.147] INFO: Hashing 2.71.199.147[500] with algo #2
2012-09-03 12:53:17: [85.244.244.244] INFO: Hashing 85.244.244.244[500] with algo #2
2012-09-03 12:53:17: INFO: Adding remote and local NAT-D payloads.
2012-09-03 12:53:17: INFO: NAT-T: ports changed to: 2.71.199.147[4500<->85.244.244.244[4500]
2012-09-03 12:53:17: INFO: KA list add: 85.244.244.244[4500]->2.71.199.147[4500]
2012-09-03 12:53:17: WARNING: unable to get certificate CRL(3) at depth:0 SubjectName:/C=SE/O=kul/OU=raby/CN=zenbook/emailAddress=xxx@gmail.com
2012-09-03 12:53:17: WARNING: unable to get certificate CRL(3) at depth:1 SubjectName:/C=SE/O=kul/OU=raby/CN=fjuttsi/emailAddress=xxx@gmail.com
2012-09-03 12:53:17: INFO: ISAKMP-SA established 85.244.244.244[4500]-2.71.199.147[4500] spi:99ded94eede882ab:d0c1c44ddebb5fdd
2012-09-03 12:53:17: INFO: respond new phase 2 negotiation: 85.244.244.244[4500]<=>2.71.199.147[4500]
2012-09-03 12:53:17: INFO: Adjusting my encmode UDP-Transport->Transport
2012-09-03 12:53:17: INFO: Adjusting peer's encmode UDP-Transport(4)->Transport(2)
2012-09-03 12:53:18: INFO: IPsec-SA established: ESP/Transport 85.244.244.244[500]->2.71.199.147[500] spi=226298888(0xd7d0c08)
2012-09-03 12:53:18: INFO: IPsec-SA established: ESP/Transport 85.244.244.244500]->2.71.199.147[500] spi=1885226050(0x705e4442)
2012-09-03 12:53:45: INFO: respond new phase 1 negotiation: 85.244.244.244[500]<=>78.108.54.10[500]
2012-09-03 12:53:45: INFO: begin Identity Protection mode.
2012-09-03 12:53:45: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2012-09-03 12:53:45: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2012-09-03 12:53:45: INFO: received Vendor ID: RFC 3947
2012-09-03 12:53:45: INFO: received Vendor ID: DPD
2012-09-03 12:53:45: [78.108.54.10] INFO: Selected NAT-T version: RFC 3947
2012-09-03 12:53:45: [85.230.57.9] INFO: Hashing 85.230.57.9[500] with algo #2
2012-09-03 12:53:45: INFO: NAT-D payload #0 verified
2012-09-03 12:53:45: [78.108.54.10] INFO: Hashing 78.108.54.10[500] with algo #2
2012-09-03 12:53:45: INFO: NAT-D payload #1 verified
2012-09-03 12:53:45: INFO: NAT not detected
2012-09-03 12:53:45: [78.108.54.10] INFO: Hashing 78.108.54.10[500] with algo #2
2012-09-03 12:53:45: [85.230.57.9] INFO: Hashing 85.230.57.9[500] with algo #2
2012-09-03 12:53:45: INFO: Adding remote and local NAT-D payloads.
2012-09-03 12:53:45: INFO: ISAKMP-SA established 85.230.57.9[500]-78.108.54.10[500] spi:85678d5b1221ecf3:07b18c9198b7ccdb
2012-09-03 12:53:45: INFO: respond new phase 2 negotiation: 85.230.57.9[500]<=>78.108.54.10[500]
2012-09-03 12:53:45: INFO: IPsec-SA established: ESP/Tunnel 85.230.57.9[500]->78.108.54.10[500] spi=92030538(0x57c464a)
2012-09-03 12:53:45: INFO: IPsec-SA established: ESP/Tunnel 85.230.57.9[500]->78.108.54.10[500] spi=3170181916(0xbcf5231c)
2012-09-03 12:53:53: INFO: purged IPsec-SA proto_id=ESP spi=1885226050.
2012-09-03 12:53:54: INFO: ISAKMP-SA expired 85.230.57.9[4500]-2.71.199.147[4500] spi:99ded94eede882ab:d0c1c44ddebb5fdd
2012-09-03 12:53:54: INFO: ISAKMP-SA deleted 85.230.57.9[4500]-2.71.199.147[4500] spi:99ded94eede882ab:d0c1c44ddebb5fdd
2012-09-03 12:53:54: INFO: KA remove: 85.230.57.9[4500]->2.71.199.147[4500]
^C2012-09-03 12:54:27: INFO: caught signal 2
2012-09-03 12:54:27: INFO: racoon process 66751 shutdown

Code:
path certificate "/usr/local/etc/racoon/certs";

listen
{
     isakmp           85.244.244.244 [500];
     isakmp_natt      85.244.244.244 [4500];
     strict_address;
}

remote anonymous {
        exchange_mode main;
        passive         on;
        ca_type x509 "ca.crt";
        certificate_type x509 "fjuttsi.crt" "fjuttsi.key";
        verify_cert on;
        my_identifier asn1dn;
        peers_identifier asn1dn;
        proposal_check obey;
#        generate_policy on;
        nat_traversal on;
        dpd_delay 20;
        ike_frag on;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group modp1024;
        }
}

sainfo anonymous {
        pfs_group modp1024;
        lifetime time 1 hour;
        encryption_algorithm aes,3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
        lifetime time 3600 sec;

mpd5.conf
Code:
# Default configuration is "dialup"

default:
        load l2tp_server

l2tp_server:
#

# Define dynamic IP address pool.
        set ippool add pool1 192.168.1.230 192.168.1.240

# Create clonable bundle template named B
        create bundle template B_l2tp
        set iface enable proxy-arp
        set iface idle 1800
        set iface enable tcpmssfix
        set ipcp yes vjcomp
# Specify IP address pool for dynamic assigment.
        set ipcp ranges 192.168.1.1/32 ippool pool1
        set ipcp dns 192.168.1.1
        set ipcp nbns 192.168.1.1
# The five lines below enable Microsoft Point-to-Point encryption
# (MPPE) using the ng_mppc(8) netgraph node type.
        set bundle enable compression
        set ccp yes mppc
        set mppc yes e40
        set mppc yes e128
        set mppc yes stateless

# Create clonable link template named L
        create link template L_l2tp l2tp
# Set bundle template to use
        set link action bundle B_l2tp
# Multilink adds some overhead, but gives full 1500 MTU.
        set link enable multilink
        set link yes acfcomp protocomp
        set link no pap chap eap
        set link enable chap
# We can use use RADIUS authentication/accounting by including
# another config section with label 'radius'.
#       load radius
        set link keep-alive 10 60
# We reducing link mtu to avoid GRE packet fragmentation.
        set link mtu 1460
# Configure L2TP
        set l2tp self 85.244.244.244
        set l2tp enable length
# Allow to accept calls
        set link enable incoming
PF is disabled during this troubleshooting.
 
marantz said:
Hello, I've got a racoon/mpd5 setup that works great with windows clients that is not behind nat. However if they are behind nat they can't connect.

Perhaps the MS KB article 947234at least explains your finding. It tells how to change something in the registry of the Windows client for letting it connect to VPN servers behind a NAT. This is on Vista, but it may work for Windows 7 too.

I did not have a chance to give it a try. In my setup I experienced very similar problems to yours, and I will try this KB by the end of the week.
 
yeah, I've read that one, but its for NAT-T servers. My server is not behind nat.

best regards
 
marantz said:
yeah, I've read that one, but its for NAT-T servers. My server is not behind nat.

best regards

Yes, the KB article is primarily talking about a server behind NAT, but inherently it is also treating clients behind NAT.

However, if you have to put a server behind a NAT device and then use an IPsec NAT-T environment, you can enable communication by changing a registry value on the VPN client computer and the VPN server.
...
A value of 2 configures Windows so that it can establish security associations when both the server and the Windows Vista-based or Windows Server 2008-based VPN client computer are behind NAT devices.

In any case, if one of both, server or client is behind NAT, then the communication should occur on port 4500, i.e. UDP-encapsulated ESP traffic for NAT-Traversal. Your server (racoon) does the switch to port 4500 automatically:

marantz said:
Code:
...
2012-09-03 12:53:17: INFO: NAT detected: PEER
2012-09-03 12:53:17: [2.71.199.147] INFO: Hashing 2.71.199.147[500] with algo #2
2012-09-03 12:53:17: [85.244.244.244] INFO: Hashing 85.244.244.244[500] with algo #2
2012-09-03 12:53:17: INFO: Adding remote and local NAT-D payloads.
2012-09-03 12:53:17: INFO: NAT-T: ports changed to: 2.71.199.147[4500<->85.244.244.244[4500]
2012-09-03 12:53:17: INFO: KA list add: 85.244.244.244[4500]->2.71.199.147[4500]
...
/code]
[/quote]

However, at least to me the KB article tells, that the Client won't even think about switching over to port 4500, if the value for the registry key [FILE] AssumeUDPEncapsulationContextOnSendRule[/FILE] is not set to 2. In effect, the server is expecting a response on port 4500, and the client keeps insisting communicating on 500.

I don't have time to check this on my setup now. I will do it later this week.
 
yeah possibly. I tried the registry hack on both win7 and win8 to no help.

Anyway I have another OpenBSD machine with ipsec/lt2p in this case with npppd. Connection to that server with the same windows machines behind nat works fine even without the registry hack.



To summarize what works.
Windows to openbsd with/without nat
windows to freebsd without nat

Kaputt.
windows to freebsd with nat
 
So the question is, has ANYONE made succesfull connections with windows 7 ipsec/lt2p (behind nat) to a freebsd racoon/mpd5 server?

If so, psk or with certs?
 
marantz said:
So the question is, has ANYONE made succesfull connections with windows 7 ipsec/lt2p (behind nat) to a freebsd racoon/mpd5 server?

If so, psk or with certs?

I haven't done it to racoon/mpd5, but we run IPSec/L2TP to a Cisco ASA from behind NAT with preshared key here with no issues on the Windows 7 side. So I don't believe it will be a Windows 7 issue that requires registry hacking.

As to why OS X works and Windows does not - Have you opened the relevant ports for NAT-T to work? If the OS X machines are behind a router that does NAT-PMP (e.g. Airport, OpenWRT, etc.), they may be doing this automatically, whilst the Windows machines may not if they are behind the same brand router, or behind a router that doesn't speak UPnP to them to open ports (Windows does not talk NAT-PMP as far as I recall).
 
I've used both specified rules for ipfw and open ipfw. Both no luck.

As I recall Cisco uses it's own client? Or it was just our model.
 
Back
Top