Juniper NetScreen vpn client won't work through pfSense, Cisco will
-
I'm running a recent RC2 build. I have somebody on the inside of my pfSense trying to connect to a Juniper VPN concentrator on the internet. The tunnel comes up, but no traffic will go through it. I have a number of Cisco software VPNs working from the inside, so there's something unique about this Juniper one.
Rules permit all trafic into LAN, and all traffic from VPN conentrator IP on the internet back into WAN. I am using NAT, and IPSec NAT traversal is enabled with the (not working) Juniper connection, as it is with the (working) Cisco connections.
We put the machine outside the pfSense directly on the internet and the tunnel worked great. We put it back inside pfSense and did some packet sniffing with a hub on the internet connection. As usual the tunnel would negotiate, but no payload comes through.
Wireshark showed malformed isakmp packets and suggested "maybe caused by "UDP checksum offload". So I experimented with turning checksum offloading off in pfSense, as well as pf scrub. Didn't make a difference. Packet dump attached.
It does seem like some kind of fragmentation thing that pfSense isn't happy about. Any ideas?
junipercap.txt -
any blocks in your firewall logs?
-
Do the Cisco ones fail too if you turn off transparent tunneling on the client (and go regular IPSEC?)
It could be because FreeBSD doesn't support NAT-T??
-
Nope, no blocks in the firewall logs whatsoever. I've got it wiiiide open for testing. Packets are just getting mangled somehow.
-
Somebody else had a similar problem a while back. No resolution reported:
http://forum.pfsense.org/index.php/topic,9669.0.html(I've tried everything in that thread already.)
-
More info:
It appears the remote VPN concentrator supports only NAT-T draft-01, which was replaced by NAT-T draft-02 because it was broken by some firewalls. Apparently draft-02 was when they started using port 4500 for payload. Before that it was port 500 for everything. So this might explain tcpdumps like this (on the LAN interface):
14:33:56.463083 IP (tos 0x0, ttl 127, id 272, offset 0, flags [none], proto UDP (17), length 128) 10.25.30.128.500 > 192.150.143.211.500: [no cksum] isakmp 1.7 msgid cookie ->: phase 2/others ? #153[EC]: [encrypted #234] (len mismatch: isakmp 2582666284/ip 100)
-
On more thing (sorry).
If I run a continuous ping through the tunnel, every once in a long while, I get a solitary reply.
When it doesn't work, tcpdump on the WAN interface looks like this. Note the "bad udp cksum" on the response:
15:21:37.183958 00:0b:db:94:4c:3f > 00:13:f7:36:4f:ac, ethertype IPv4 (0x0800), length 142: (tos 0x0, ttl 126, id 49678, offset 0, flags [none], proto UDP (17), length 128) 74.93.31.17.59491 > 192.150.143.211.500: [no cksum] isakmp 4.14 msgid cookie ->: phase 2/others ? #214[C]: [|#200] (len mismatch: isakmp 2089828598/ip 100)
15:21:37.220137 00:13:f7:36:4f:ac > 00:0b:db:94:4c:3f, ethertype IPv4 (0x0800), length 142: (tos 0x20, ttl 52, id 28569, offset 0, flags [none], proto UDP (17), length 128) 192.150.143.211.500 > 74.93.31.17.59491: [bad udp cksum dea7!] isakmp 9.15 msgid cookie ->: phase 2/others ? #138[C]: [|#164] (len mismatch: isakmp 2342990064/ip 100)When it does work, it looks like this. Note the "udp sum ok" on the response packet.
15:21:48.179080 00:0b:db:94:4c:3f > 00:13:f7:36:4f:ac, ethertype IPv4 (0x0800), length 142: (tos 0x0, ttl 126, id 6906, offset 0, flags [none], proto UDP (17), length 128) 74.93.31.17.59491 > 192.150.143.211.500: [no cksum] isakmp 15.11 msgid cookie ->: phase 2/others ? #124[EC]: [encrypted #117] (len mismatch: isakmp 2676507093/ip 100)
15:21:48.217091 00:13:f7:36:4f:ac > 00:0b:db:94:4c:3f, ethertype IPv4 (0x0800), length 142: (tos 0x20, ttl 52, id 28678, offset 0, flags [none], proto UDP (17), length128) 192.150.143.211.500 > 74.93.31.17.59491: [udp sum ok] isakmp 8.8 msgid cookie->: phase 2/others ? #134[C]: [|ke] (len mismatch: isakmp 168770057/ip 100)It seems like checksums are wrong because of some kind of mangling, but every once in a while the mangled packet checksum ends up actually being right? Just a "monkeys on typewriters" kind of a thing?
