IPSEC traffic going over WAN vs Tunnel

eri--

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.

shon

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

MLIT

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

shon

Nope, no load balancing rules

dotdash

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?

voleatech

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.

eri--

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

voleatech

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

shon

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)

???

dotdash

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.

shon

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.

eri--

@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?!!

shon

tunnel mode

voleatech

@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.

eri--

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

eri--

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

voleatech

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