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

    IPSEC traffic going over WAN vs Tunnel

    Scheduled Pinned Locked Moved IPsec
    18 Posts 5 Posters 2.6k 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
      MLIT
      last edited by

      Do you have any special load balancing rules? –- Something like that might force traffic out the WAN versus the IPSEC tunnel.

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

        Nope, no load balancing rules

        1 Reply Last reply Reply Quote 0
        • dotdashD
          dotdash
          last edited by

          This seems, as Ralph Wiggum might say, unpossible.
          IPSec runs in the kernel and should trump the routing table and lan rules.
          Anything strange in the IPSEC rules tab? Possibly a route on the client machine?
          Why don't you expand the phase2 to include the lan side of the firewalls and see if you can source a ping from the lan interface of one firewall to the other?

          1 Reply Last reply Reply Quote 0
          • V
            voleatech
            last edited by

            I can confirm that I have the same issue private IP from IPSec tunnel is leaving the WAN interface.
            It is related to my other issue in the post https://forum.pfsense.org/index.php?topic=93372.0 .
            Any help is appreciated.

            1 Reply Last reply Reply Quote 0
            • E
              eri--
              last edited by

              Can you provide an output of setkey -PD and setkey -D

              1 Reply Last reply Reply Quote 0
              • V
                voleatech
                last edited by

                setkey -PD output is:

                192.168.6.0/24[any] 192.168.6.1[any] any
	in none
	created: May 10 16:25:12 2015  lastused: May 14 17:26:45 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=2 seq=7 pid=7906
	refcnt=1
172.16.0.0/15[any] 192.168.4.0/22[any] any
	in ipsec
	esp/tunnel/46.232.185.36-46.237.244.223/unique:1
	created: May 14 11:31:31 2015  lastused: May 14 17:28:04 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=94 seq=6 pid=7906
	refcnt=1
192.168.250.1[any] 192.168.6.0/24[any] any
	in ipsec
	esp/tunnel/46.237.248.107-46.237.244.223/unique:11
	created: May 14 17:27:36 2015  lastused: May 14 17:28:04 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=98 seq=5 pid=7906
	refcnt=1
192.168.250.1[any] 192.168.5.0/24[any] any
	in ipsec
	esp/tunnel/46.237.248.107-46.237.244.223/unique:12
	created: May 14 17:27:40 2015  lastused: May 14 17:28:04 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=102 seq=4 pid=7906
	refcnt=1
192.168.6.1[any] 192.168.6.0/24[any] any
	out none
	created: May 10 16:25:12 2015  lastused: May 14 17:26:45 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=1 seq=3 pid=7906
	refcnt=1
192.168.4.0/22[any] 172.16.0.0/15[any] any
	out ipsec
	esp/tunnel/46.237.244.223-46.232.185.36/unique:1
	created: May 14 11:31:31 2015  lastused: May 14 17:27:57 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=93 seq=2 pid=7906
	refcnt=1
192.168.6.0/24[any] 192.168.250.1[any] any
	out ipsec
	esp/tunnel/46.237.244.223-46.237.248.107/unique:11
	created: May 14 17:27:36 2015  lastused: May 14 17:28:04 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=97 seq=1 pid=7906
	refcnt=1
192.168.5.0/24[any] 192.168.250.1[any] any
	out ipsec
	esp/tunnel/46.237.244.223-46.237.248.107/unique:12
	created: May 14 17:27:40 2015  lastused: May 14 17:28:04 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=101 seq=0 pid=7906
	refcnt=1

                the output of setkey -D is:

                46.237.244.223 46.237.248.107 
	esp mode=tunnel spi=129049066(0x07b121ea) reqid=12(0x0000000c)
	E: rijndael-cbc  395611f5 f2dd77e7 e9ec1918 59da8424 297391e2 7db9feb8 c1da9c5c bbaacfe1
	A: hmac-sha1  8acb2b54 5fd25524 0654e756 319f5894 ff5d6810
	seq=0x00000218 replay=4 flags=0x00000000 state=mature 
	created: May 14 17:27:40 2015	current: May 14 17:28:31 2015
	diff: 51(s)	hard: 28800(s)	soft: 28259(s)
	last: May 14 17:28:27 2015	hard: 0(s)	soft: 0(s)
	current: 325200(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 536	hard: 0	soft: 0
	sadb_seq=5 pid=35479 refcnt=2
46.237.248.107 46.237.244.223 
	esp mode=tunnel spi=3381816323(0xc9926c03) reqid=12(0x0000000c)
	E: rijndael-cbc  2510c709 aeee0bb9 24113962 bc2ad269 2a471672 4648f1de f7af94ac 78e693bd
	A: hmac-sha1  ae14570a 9c08f71c 7c23d7bb c28daa01 0f5ae94f
	seq=0x00000327 replay=4 flags=0x00000000 state=mature 
	created: May 14 17:27:40 2015	current: May 14 17:28:31 2015
	diff: 51(s)	hard: 28800(s)	soft: 27765(s)
	last: May 14 17:28:27 2015	hard: 0(s)	soft: 0(s)
	current: 157725(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 807	hard: 0	soft: 0
	sadb_seq=4 pid=35479 refcnt=1
46.237.244.223 46.237.248.107 
	esp mode=tunnel spi=136617701(0x08249ee5) reqid=11(0x0000000b)
	E: rijndael-cbc  1a798693 321fafc9 afa11782 af260d4c 9bfb8ff4 936f4a4f fa4a537f 5c59b699
	A: hmac-sha1  44c0b81f c7a405e0 667b9de4 8ef86e15 66f14661
	seq=0x000000d2 replay=4 flags=0x00000000 state=mature 
	created: May 14 17:27:36 2015	current: May 14 17:28:31 2015
	diff: 55(s)	hard: 28800(s)	soft: 28037(s)
	last: May 14 17:28:31 2015	hard: 0(s)	soft: 0(s)
	current: 50336(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 210	hard: 0	soft: 0
	sadb_seq=3 pid=35479 refcnt=2
46.237.248.107 46.237.244.223 
	esp mode=tunnel spi=3394828983(0xca58fab7) reqid=11(0x0000000b)
	E: rijndael-cbc  81e4945d bf81334c b079f164 e155ffad 1727112c dfe22f14 eeeb5105 4d6251c4
	A: hmac-sha1  452f3994 14cece17 8f484659 d94ea7c2 4e44f91d
	seq=0x000000e0 replay=4 flags=0x00000000 state=mature 
	created: May 14 17:27:36 2015	current: May 14 17:28:31 2015
	diff: 55(s)	hard: 28800(s)	soft: 27794(s)
	last: May 14 17:28:31 2015	hard: 0(s)	soft: 0(s)
	current: 30531(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 224	hard: 0	soft: 0
	sadb_seq=2 pid=35479 refcnt=1
46.237.244.223 46.232.185.36 
	esp mode=tunnel spi=209212608(0x0c7854c0) reqid=1(0x00000001)
	E: rijndael-cbc  878b3506 cc3cd797 2bae1aac a2afd80d 9c817086 8870227c 61e5f402 6b3fd4b8
	A: hmac-sha1  f7532ab5 3ac193dc 8c302482 49f2b191 fe5cbc78
	seq=0x00001336 replay=4 flags=0x00000000 state=mature 
	created: May 14 11:31:31 2015	current: May 14 17:28:31 2015
	diff: 21420(s)	hard: 28800(s)	soft: 27782(s)
	last: May 14 17:27:57 2015	hard: 0(s)	soft: 0(s)
	current: 2193128(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 4918	hard: 0	soft: 0
	sadb_seq=1 pid=35479 refcnt=2
46.232.185.36 46.237.244.223 
	esp mode=tunnel spi=3304683156(0xc4f97694) reqid=1(0x00000001)
	E: rijndael-cbc  22480517 b4024ef9 dd1985a2 a218c38b 4d39f527 832e462d d9ea9fcc e120333b
	A: hmac-sha1  caace7db 0f264378 7dbd4554 6b582edc 09fc0d4e
	seq=0x00001ff2 replay=4 flags=0x00000000 state=mature 
	created: May 14 11:31:31 2015	current: May 14 17:28:31 2015
	diff: 21420(s)	hard: 28800(s)	soft: 28193(s)
	last: May 14 17:28:10 2015	hard: 0(s)	soft: 0(s)
	current: 2334946(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 8178	hard: 0	soft: 0
	sadb_seq=0 pid=35479 refcnt=1

                I have one IPSec mobile tunnel (192.168.250.0/24) with 3 Phase 2 Entries (192.168.4.0/24,192.168.5.0/24,192.168.6.0/24) and one IPSec tunnel ikev1 to a pfSense 2.1.5 with a single P2 (192.168.4.0/22 <-> 172.16.0.0/15).

                The issue happens (packets leaving WAN instead of going through the tunnel) when I try to reach any client in 172.17.0.0/16, I can reach clients in the 172.16.0.0/16 range just fine.

                Best
                Sven

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

                  I've been able to reproduce the problem now.

                  Packets go outside of my WAN in this p2 mode

                  SITE A = 172.31.100.1/32 (Watchguard FW)
                  SITE B = 172.31.10.1/32 (pFsense 2.2.2 x64)

                  Packets are routing appropriately ( not going out of the WAN) with a mis-matched configuration as such:

                  SITE A = 172.31.100.1/32 (Watchguard FW)
                  SITE B  = 172.31.10.0/24 (pfsense 2.2.2 x64)

                  ???

                  1 Reply Last reply Reply Quote 0
                  • dotdashD
                    dotdash
                    last edited by

                    Are you sure the problem isn't the Watchguard? Are you specifying just the IP address on the WG, or trying to use a /32 subnet? I think on the WG, you need to just put in the IP without a mask.

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

                      Yes the WG settings are correct.

                      Wouldn't my packets destine for SITE A, from SITE B still try to encapsulated by the pfsense firewall based on the SRC/DST headers?

                      I'd imagine the packets would not go over the tunnel if the p2 settings are incorrect , but that still should not send them over the WAN.

                      1 Reply Last reply Reply Quote 0
                      • E
                        eri--
                        last edited by

                        @shon
                        You are trying to setup transport mode or tunnel mode.

                        @voleatech
                        From the output of your setkey i see that the tunnel is being used and still do not understand your issue?!!

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

                          tunnel mode

                          1 Reply Last reply Reply Quote 0
                          • V
                            voleatech
                            last edited by

                            @ermal

                            The issue is:

                            SITE A: 192.168.4.0/22
                            SITE B: 172.16.0.0/15

                            Pinging Site B in 172.17.X.X from Site A does not work.
                            The traffic leaves the WAN interface instead of going into the tunnel.

                            1 Reply Last reply Reply Quote 0
                            • E
                              eri--
                              last edited by

                              Well the last thing to see here is the pf rules.
                              Show me the /tmp/rules.debug if you do not want that public send it to eri at pfsense.org

                              1 Reply Last reply Reply Quote 0
                              • E
                                eri--
                                last edited by

                                After seeing your rules is clear, your issue is you have disabled negate rules :)

                                1 Reply Last reply Reply Quote 0
                                • V
                                  voleatech
                                  last edited by

                                  Hi,

                                  I just saw it myself :)
                                  I have a typo in my aliases I put in a /16 instead of /12 in my private network alias for 172.16.0.0

                                  Thanks for your help ermal

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