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

    [resolved]IPSec Site-to-Site VPN passes only some Traffic

    Scheduled Pinned Locked Moved IPsec
    2 Posts 1 Posters 1.5k 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.
    • M
      mhecker
      last edited by

      Hello pfSense community,

      we are currently implementing a new firewall system based on pfSense. Routing and firewall rules to control access between our local VLANs is working fine - we passed our test schedule implementing restrictions between guest, employee and management VLANs. We have configured QoS / Traffic Shaping for our VoIP phones already.

      So far we are quite happy with our project going on at a good pace, but the last two days we focused on Site to Site VPNs using IPSec and ran into the following problems:

      Our new pfSense at Main-Office:
      pfSense Version: 2.2.2-Release (amd64)
      Equipped with 3 Dual-Port Intel NICs (igb0, igb1, igb2, igb3, em0, em1)

      Current Network Configuration
      igb3: LAN 10.100.10.254, Network 10.100.10.0/24
      igb2: WAN with pppoe0 dial-in / fixed IPv4 address assigned by ISP
      igb0 + em0 bonded as lagg0 in Failover-mode attached to 2 different Switches

      We have several VLANs attached to lagg0, for IPSec testing we used two of those networks:
      lagg0_vlan10: 10.100.10.253, Network: 10.100.10.0/24 (same Network as LAN / Management Network)
      lagg0_vlan110: 10.100.110.254, Network: 10.100.110.0/24 (Employee Network)
      etc.

      Two Branch-Offices running Funkwerk / bintec rs120 respectively rs353jw devices
      Branch-Office 1:
      bintec rs120
      Router IP: 192.168.2.1
      Local subnet: 192.168.2.0/24

      Branch-Office 2:
      bintec rs353jw
      Router IP: 192.168.102.1
      Local subnet: 192.168.102.0/24

      What works:
      Scenario 1: VPN configured to use 10.100.10.0/24 as local subnet

      • IPSec tunnels are working
      • Inbound traffic from both branch offices to our main office is always working
        – 192.168.2.0/24 -> 10.100.10.0/24
        -- 192.168.102.0/24 -> 10.100.10.0/24
      • Outbound traffic originating from LAN-Interface to the branch-offices is working if the LAN network is configured in the phase 2 profile.
        -- 10.100.10.0/24 -> 192.168.2.0/24
        -- 10.100.10.0/24 -> 192.168.102.0/24

      Scenario 2: VPN configured to use 10.100.110.0/24 as local subnet

      • IPSec tunnels are working
      • Inbound traffic from both branch offices to our main office is always working
        -- 192.168.2.0/24 -> 10.100.110.0/24
        -- 192.168.102.0/24 -> 10.100.110.0/24
      • Outbound traffic originating from LAN-Interface to the branch-offices is working if the LAN network is configured in the phase 2 profile.
        -- 10.100.110.0/24 -> 192.168.102.0/24

      However, in this scenario the following way does not work:
      -- 10.100.110.0/24 -> 192.168.2.0/24
      No packets appear on tcpdump -i enc0 or blocked by the firewall.

      We added a third tunnel to scenario 2 with an additional remote network 192.168.0.0/24 that showed the same behaviour as the 192.168.2.0/24 network. The 192.168.102.0/24 tunnel is still working both ways here, both other tunnels only work one-way.

      We added a wildcard rule (pass, source: *, destination: , protocol: ipv4) to the IPSec interface in the firewall settings.

      ipsec statusall shows all IP Addresses configured as listening for every configured IPSec connection.

      Output of setkey -DP

      
      192.168.0.0/24[any] 10.100.110.0/24[any] any
              in ipsec
              esp/tunnel/<branch3-remote>-
      
      <main office="">/unique:3
              created: Jun 17 14:03:27 2015  lastused: Jun 17 14:03:27 2015
              lifetime: 9223372036854775807(s) validtime: 0(s)
              spid=522 seq=5 pid=85741
              refcnt=1
      192.168.102.0/24[any] 10.100.110.0/24[any] any
              in ipsec
              esp/tunnel/<branch2-remote>-
      
      <main office="">/unique:2
              created: Jun 17 14:03:40 2015  lastused: Jun 17 14:24:05 2015
              lifetime: 9223372036854775807(s) validtime: 0(s)
              spid=526 seq=4 pid=85741
              refcnt=1
      192.168.2.0/24[any] 10.100.10.0/24[any] any
              in ipsec
              esp/tunnel/<branch1-remote>-
      
      <main office="">/unique:1
              created: Jun 17 14:12:28 2015  lastused: Jun 17 14:14:07 2015
              lifetime: 9223372036854775807(s) validtime: 0(s)
              spid=532 seq=3 pid=85741
              refcnt=1
      10.100.110.0/24[any] 192.168.0.0/24[any] any
              out ipsec
              esp/tunnel/
      
      <main office="">-<branch3-remote>/unique:3
              created: Jun 17 14:03:27 2015  lastused: Jun 17 14:03:27 2015
              lifetime: 9223372036854775807(s) validtime: 0(s)
              spid=521 seq=2 pid=85741
              refcnt=1
      10.100.110.0/24[any] 192.168.102.0/24[any] any
              out ipsec
              esp/tunnel/
      
      <main office="">-<branch2-remote>/unique:2
              created: Jun 17 14:03:40 2015  lastused: Jun 17 14:24:05 2015
              lifetime: 9223372036854775807(s) validtime: 0(s)
              spid=525 seq=1 pid=85741
              refcnt=1
      10.100.10.0/24[any] 192.168.2.0/24[any] any
              out ipsec
              esp/tunnel/
      
      <main office="">-<branch1-remote>/unique:1
              created: Jun 17 14:12:28 2015  lastused: Jun 17 14:14:07 2015
              lifetime: 9223372036854775807(s) validtime: 0(s)
              spid=531 seq=0 pid=85741
             refcnt=1
      
      We appreciate your help!</branch1-remote></main></branch2-remote> </main></branch3-remote> </main>
      
      </main></branch1-remote> </main></branch2-remote> </main></branch3-remote> 
      
      1 Reply Last reply Reply Quote 0
      • M
        mhecker
        last edited by

        Hello community,

        we resolved this issue with help from the pfSense support.

        First of Steve pointed out that our LAN and VLAN10 interfaces were on the same subnet which may cause problems, thus we removed the VLAN10 from our bonded interface to be on the safe side.

        The actual problem was caused by firewall rules blocking access to RFC1918 subnets from the local VLANs to our remote networks.

        We had a pass rule for the remote subnets, but this rule was on the wrong interface group. We enabled logging on every block/reject rule that we had in place and those packets appeared as rejected by another interface group's reject-rule. Moving the pass-rules to the correct interface group fixed the issue.

        Kind regards

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