IPSec policy-based VPN (vs route-based VPN)
-
Hi everyone,
I needed to setup a site-to-site IPSec connection between a pfSense and a Cisco firewall (don't know exactly which type). After alot of finicking we got the tunnel up between both firewalls, but no traffic was passing the tunnel (could not ping or traceroute devices on the other end). I searched & searched for solutions to no avail, and today I got a message from the sysadmin who manages the firewall on the other end that he knew what was causing the problem. He wrote to me: "I was under the assumption that pfSense could transparently setup route-based and policy-based VPN's. We only allow policy-based VPN's, route-based VPN's are out of the question."
I started searching to find some info on whether pfSense supports those "policy-based" VPN's, but cannot find a clear answer.
If pfSense cannot do it, then we will need to buy a Juniper or Cisco device to connect to this client.
So: can anyone tell me whether this is possible using pfSense please?
Info: we're running nightlies from RC0.Thanks in advance!
-
Not sure what that person was on that day, but all pfSense supports is policy-based IPsec from that point of view.
-
So you're saying it's just a semantic discussion jimp?
These pages tell me other things:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB4124
http://www.juniper.net/techpubs/en_US/junos/topics/concept/policy-based-route-based-vpn-comparing.html
http://www.internet-computer-security.com/VPN-Guide/Policy-based-vs-Route-based-VPN.html
http://forums.juniper.net/t5/ScreenOS-Firewalls-NOT-SRX/Policy-Based-VPN-or-Route-based-VPN/td-p/40818
http://forums.juniper.net/t5/ScreenOS-Firewalls-NOT-SRX/Route-based-VPNs-or-Policy-based-VPNs-Which-one-is-better/td-p/23116I cannot seem to find any open source firewall/router distro that does support those policy-based VPN's either.
The company we need to deal with is a very large company and they have strict policies for interaction with external parties, no exceptions allowed.
I would hate to realize that all the effort that has been made to get the tunnel up has been for nothing, and we would still need to buy that Juniper/Cisco because of that policy restriction :-/ -
Route-based needs a tunnel interface (which we don't have) and lets you use routes (as the name implies) on the VPN – which we don't support.
Policy-based uses Phase 2 definitions to define IPsec policies that control what traffic enters the tunnel. That is what practically -every- IPsec implementation does from any device, from little Linksys devices to OSS firewall distributions like pfSense and such.
Route-based IPsec is extraordinarily rare by comparison.
-
Well, thank you for clearing that one up for me jimp!
So, if I understand you correctly, then if the tunnel is up (which is the case) and the necessary firewall rules are in place (also the case), then the traffic from my source subnet defined in Phase 2 will get routed through the tunnel by pfSense automatically? Is there any way I can sniff the packets or can I prove one way or another that traffic from our end is indeed going in the tunnel? That would absolutely give me something to work with!
For the sake of being complete: our end of the tunnel is defined with a subnet (10.1.10.0/24) that is defined on a separate physical interface (re3). This interface was enabled, given a static IP of 10.1.10.1/24, and has a DHCP server running on it. DNS forwarder is active on all interfaces. WAN is up and functioning correctly, LAN works without problems, 2 other interfaces (DMZ & visitor WLAN) work correct too, and I have another IPSec server + a OpenVPN server running on pfSense for road warriors. If I run a packet capture on the WAN interface, I see no captures when I ping or traceroute an address on the other side of the tunnel (that seems normal). But how can I capture packets going into the tunnel then? The sysadmin on the other end of the tunnel tells me they never see any traffic arriving, and I have no way of proving the error must be on their side then. Very frustrating…
-
In the packet capture screen, choose "IPsec" as the interface. It will then show you what is happening in the tunnel.
(The interface is enc0 when used from the shell)
-
Great, thanks jimp!
I now get this from a packet capture on the IPSec interface when pinging an address on the other side of the tunnel.
Is that sufficient to prove that traffic is indeed entering the tunnel?
Why am I seeing those "bad checksum" messages here?20:04:00.115016 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 36578, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 506 (->ea8d)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 0, length 64 20:04:01.116111 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 19068, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 45ff (->2ef4)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 1, length 64 20:04:02.117098 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 1782, offset 0, flags [none], proto ICMP (1), length 84, bad cksum c610 (->727a)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 2, length 64 20:04:03.118096 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 41910, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->d5b9)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 3, length 64 20:04:04.119083 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 54735, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 909 (->a3a0)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 4, length 64 20:04:05.120087 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 100, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->790c)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 5, length 64 20:04:06.121071 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 54963, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->a2bc)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 6, length 64 20:04:07.122069 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 7564, offset 0, flags [none], proto ICMP (1), length 84, bad cksum bff4 (->5be4)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 7, length 64 20:04:08.123059 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 25411, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->162d)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 8, length 64 20:04:09.124059 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 4866, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->666e)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 9, length 64 20:04:10.125060 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 24073, offset 0, flags [none], proto ICMP (1), length 84, bad cksum fed1 (->1b67)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 10, length 64 20:04:11.126046 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 61032, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->8b07)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 11, length 64 20:04:12.127037 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 62437, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->858a)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 12, length 64 20:04:13.128031 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 48610, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->bb8d)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 13, length 64 20:04:14.129025 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 763, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->7675)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 14, length 64 20:04:15.130030 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 19291, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->2e15)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 15, length 64 20:04:16.131022 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 1401, offset 0, flags [none], proto ICMP (1), length 84, bad cksum bff4 (->73f7)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 16, length 64 20:04:17.132048 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 37177, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->e836)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 17, length 64 20:04:18.133020 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 34185, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 500a (->f3e6)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 18, length 64 20:04:19.134012 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 22158, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->22e2)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 19, length 64 20:04:20.135005 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 3790, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->6aa2)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 20, length 64 20:04:21.135989 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 7248, offset 0, flags [none], proto ICMP (1), length 84, bad cksum f03b (->5d20)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 21, length 64 20:04:22.136978 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 45071, offset 0, flags [none], proto ICMP (1), length 84, bad cksum bff4 (->c960)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 22, length 64 20:04:23.137976 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 9445, offset 0, flags [none], proto ICMP (1), length 84, bad cksum dcdc (->548b)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 23, length 64 20:04:24.138974 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 37597, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->e692)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 24, length 64 20:04:25.139975 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 55487, offset 0, flags [none], proto ICMP (1), length 84, bad cksum bff4 (->a0b0)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 25, length 64 20:04:26.140958 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 49622, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->b799)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 26, length 64 20:04:27.141966 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 47451, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->c014)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 27, length 64 20:04:28.142945 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 35607, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 8a9b (->ee58)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 28, length 64 20:04:29.143941 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 31119, offset 0, flags [none], proto ICMP (1), length 84, bad cksum bff4 (->ffe0)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 29, length 64 20:04:30.144941 (authentic,confidential): SPI 0x1b9f71c2: (tos 0x0, ttl 64, id 51182, offset 0, flags [none], proto ICMP (1), length 84, bad cksum c9e7 (->b181)!) 10.1.10.1 > 17x.y.z.z7: ICMP echo request, id 15686, seq 30, length 64
The routing policy seems to be working fine though, because when I ping another address, there are no packets captured on the IPSec interface, and I do get replies:
[2.1-RC0][root@pfsense.lmr]/root(2): ping -S 10.1.10.1 www.marjoleindens.be PING www.marjoleindens.be (209.123.234.72) from 10.1.10.1: 56 data bytes 64 bytes from 209.123.234.72: icmp_seq=0 ttl=52 time=89.218 ms 64 bytes from 209.123.234.72: icmp_seq=1 ttl=52 time=89.150 ms 64 bytes from 209.123.234.72: icmp_seq=2 ttl=52 time=89.346 ms 64 bytes from 209.123.234.72: icmp_seq=3 ttl=52 time=88.192 ms 64 bytes from 209.123.234.72: icmp_seq=4 ttl=52 time=88.829 ms
IPSec status:
SPD status:
SAD status:
-
This sounds almost identical to our problem http://forum.pfsense.org/index.php/topic,63372.0.html
We suspect it might be due to:
(1) Checksum calculations, so we have disable net.inet.udp.checksum using sysctrl/system tunables
(2) IPSec to NAT priority (but that would stop the DPD packets aswell)
(3) Mismatch of MTU between Juniper (default 1500) and default MTU of enc0 on pfSense (default 1536) which we cannot fathom how to change at this juncture
OR possibly…
(4) Removing DF (donotfragment) using scrub
-
We resolved our issue by checking that no intermediary device was blocking ESP protocol traffic.
Even though SA "exchange/handshake" was completed and DPD transferring over UDP 500… ESP transfer was our root cause!