Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSec policy-based VPN (vs route-based VPN)

    Scheduled Pinned Locked Moved IPsec
    9 Posts 3 Posters 12.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sventunus
      last edited by

      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!

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        Not sure what that person was on that day, but all pfSense supports is policy-based IPsec from that point of view.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • S
          sventunus
          last edited by

          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/23116

          I 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 :-/

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            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.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • S
              sventunus
              last edited by

              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…

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                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)

                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • S
                  sventunus
                  last edited by

                  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:

                  1 Reply Last reply Reply Quote 0
                  • C
                    contentengineer
                    last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • C
                      contentengineer
                      last edited by

                      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!

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.