VPN pfSense to Juniper SSG140 - Phase 2 negotiates, no data transfer
-
We are adding an additional VPN to our SSG140's using pfSense to enable a client to connect to a server using ssh via an existing internet router. This is the first pfSense VPN, others are Juniper. There is a router between pfSense which is setup with Open Ports UDP 500/4500 mapping x.x.x.x to 192.168.1.223.
client LAN 172.30.20.111 <-> pfSense LAN 172.30.20.10 WAN 192.168.1.223 <-> router LAN 192.168.1.254 WAN x.x.x.x
<-> [Internet] <-> SSG140 WAN y.y.y.y SSG140 LAN 172.20.10.1 <-> server 172.20.10.59Tunnel from 172.30.20.0/24 <-> 172.16.10.0/16 setup on pfSense and SSG140
Status:
Phase 1 and Phase 2 negotiations complete OK
IPSec status on pfSense showing green
IPSec status on SSG140 showing link ready (monitoring is disabled)
Racoon debug shows that DPD "keepalives" are being transferred every 10 secondsData is showing in SAD on pfSense indicates actual traffic may be one way:
192.168.1.223 -> y.y.y.y 81345Bytes (after many connections)
y.y.y.y -> 192.168.1.223 0BytesProblem:
Unable to ssh from client to server
Unable to ping from client to server (though this could be down to FreeBSD issues)Need to determine the route cause as it appears that data is transferring over the wire from the pfSense but not reaching the SSG140.
Attached are racoon config, spd info and rules.debug.
Any help gratefully received!
Cheers
racoon_clean_conf.txt
spd_clean_conf.txt
tmp_rules_clean_debug.txt -
Attached is the cleaned config from the SSG140 showing tunnel definition (Tunnel 9) and routing information.
This is the fourth VPN on the SSG140, all others are working fine (SSG140<->SSG140).Monitoring is disabled on tunnel.9
-
Here is the log output (non-debug) showing successful SA phase 2 negotiations:
Jun 12 15:14:24 racoon: [XXXXX Remote IPSEC Test]: INFO: IPsec-SA request for y.y.y.y queued due to no phase1 found.
Jun 12 15:14:24 racoon: [XXXXX Remote IPSEC Test]: INFO: initiate new phase 1 negotiation: 192.168.1.223[500]<=>y.y.y.y[500]
Jun 12 15:14:24 racoon: INFO: begin Identity Protection mode.
Jun 12 15:14:24 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jun 12 15:14:24 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
Jun 12 15:14:24 racoon: INFO: received Vendor ID: DPD
Jun 12 15:14:25 racoon: [XXXXX Remote IPSEC Test]: INFO: ISAKMP-SA established 192.168.1.223[500]-y.y.y.y[500] spi:b437249987cd56e9:d01ec978041af980
Jun 12 15:14:25 racoon: [XXXXX Remote IPSEC Test]: INFO: initiate new phase 2 negotiation: 192.168.1.223[500]<=>y.y.y.y[500]
Jun 12 15:14:26 racoon: WARNING: attribute has been modified.
Jun 12 15:14:26 racoon: [XXXXX Remote IPSEC Test]: INFO: IPsec-SA established: ESP 192.168.1.223[500]->y.y.y.y[500] spi=164820588(0x9d2f66c)
Jun 12 15:14:26 racoon: [XXXXX Remote IPSEC Test]: INFO: IPsec-SA established: ESP 192.168.1.223[500]->y.y.y.y[500] spi=1162780118(0x454e9dd6) -
Packet capture on IPSec interface is showing checksum errors (both icmp and tcp traffic). This is a packet capture for ssh connection across the wire:
15:59:27.065630 (authentic,confidential): SPI 0x454e9dd8: (tos 0x0, ttl 63, id 21173, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 70bb (->71bb)!)
172.30.20.222.47377 > 172.20.10.59.22: Flags, cksum 0xfc1a (correct), seq 2079263666, win 14600, options [mss 1460,sackOK,TS val 29448455 ecr 0,nop,wscale 7], length 0
15:59:28.064096 (authentic,confidential): SPI 0x454e9dd8: (tos 0x0, ttl 63, id 21174, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 70ba (->71ba)!)
172.30.20.222.47377 > 172.20.10.59.22: Flags, cksum 0xf832 (correct), seq 2079263666, win 14600, options [mss 1460,sackOK,TS val 29449455 ecr 0,nop,wscale 7], length 0
15:59:30.063932 (authentic,confidential): SPI 0x454e9dd8: (tos 0x0, ttl 63, id 21175, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 70b9 (->71b9)!)
172.30.20.222.47377 > 172.20.10.59.22: Flags, cksum 0xf062 (correct), seq 2079263666, win 14600, options [mss 1460,sackOK,TS val 29451455 ecr 0,nop,wscale 7], length 0 -
Would be interested to hear if anyone knows what is going on here, as I have the exact same problem with an exact same connection between pfSense and a Juniper device (only difference being there is no router behind my pfSense). See this post.
-
From the data being lopsided in the SPD, there are a couple possibilities:
1. System > Advanced, Misc tab, Uncheck Prefer Old IPsec SA
2. The traffic is making it to the Juniper but not allowed by policy there (not a tunnel issue, but firewall)If the tunnel establishes, the tunnel config is usually fine.
The checksums aren't anything to really worry about, on the enc0 interface that isn't unusual to see.
If you need to adjust the MTU of the tunnel, you can't do that directly but you can setup MSS clamping for it which is also under System > Advanced on the Misc tab.
I've setup several tunnels between pfSense and Juniper and haven't had very many issues along the way. Usually it's that the Juniper side didn't have something set right in the tunnel to match pfSense or vice versa, but that would prevent the tunnel from establishing.
-
Thanks for your advice. We believe that it is working now with some minor changes to the pfSense end.
We have gone back to basics on IPSec.
Since the Security Associations (SA) were being established between the two sites, but traffic was flowing OUTOF the pfSense (to somewhere) but not flowing INTO the pfSense from the second site (from y.y.y.y); and no traffic was being received at the second site. We assumed that there must be some device in the way that was blocking the data traffic.
Since the data traffic is handled on ESP Protocol, something must be blocking that.
Changing the router configuration, so instead of using open ports (UDP 500) for NAT, we tested by using a DMZ/address map. As soon as this was changed, data started to flow and SSH connections could be made.
We also made it more robust by adding a gateway definition for the LAN interface and Firewall rules to pfSense to run LAN 172.20.0.0/16 via the LAN GW. Belt and braces really (plus enables better fault finding).
During this process we ruled out red herrings such as:
- IPV6 redirection issues
- Routing table issues on the SSG140's
- Firewall policies on the SSG140's
- Scrub
This experience leads me to favour pfSense over packaged Juniper products (e.g. SSG140):
- Better overall fault diagnosis than Juniper
- Better tracing of traffic
- Better tuning of configuration parameters
- Better log information