IPSEC traffic going over WAN vs Tunnel
-
I have a VPN tunnel setup between two sites just allowing two hosts to communicate with each other from their respective subnets
SITE A = 172.31.100.1/32
SITE B = 172.31.10.1/32The issue is that pfsense is sending traffic destine for the IPSEC tunnel over the WAN vs encrypting the packets and sending them over the tunnel. I can see that by running traceroute. I've looked at the P2 entries to make sure I had the right entries in there many times. I've tried specifying the host, by address, and network (ending it in a /32) with no change.
How are these packets suppose to be processed? Where can I view this order of processing?
I'm running version 2.2.2
-
The only way that can happen is that the sysctl for allowing ipsec is deactivated.
sysctl net.inet.ipsec.enable or similar should be 1 for IPsec to work.
I have not seen that happen it not being set when needed unless overriden manaully or by wrong userland and kernel. -
The IPSEC tunnel is up between the sites, and the service was running before but the packets are still being sent out of the gateway.
I'm able to verify it via the shell: sysctl -a | grep ipsec
-
Do you have any special load balancing rules? –- Something like that might force traffic out the WAN versus the IPSEC tunnel.
-
Nope, no load balancing rules
-
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? -
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. -
Can you provide an output of setkey -PD and setkey -D
-
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 -
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)???
-
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.
-
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.
-
@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?!! -
tunnel mode
-
@ermal
The issue is:
SITE A: 192.168.4.0/22
SITE B: 172.16.0.0/15Pinging 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. -
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 -
After seeing your rules is clear, your issue is you have disabled negate rules :)
-
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.0Thanks for your help ermal