> I'm sorry to say this but that was unnecessary because you can disable the
> plugins in the configuration. You do not need to recompile anything.
>
Well it was a learning experience for me :)
I looked in the stock EPEL configuration directories created for strongswan.
/etc/strongswan/strongswan.d/charon/kernel-libipsec.conf had "load=yes".
I changed this to "load=no" on both systems and restarted strongswan
Now I get:
[root@CentralRouter]# strongswan up CentralEast
establishing CHILD_SA CentralEast{8}
generating CREATE_CHILD_SA request 0 [ SA No TSi TSr ]
sending packet: from WW.XX.YY.ZZ[4500] to AA.BB.CC.DD[4500] (620 bytes)
received packet: from AA.BB.CC.DD[4500] to WW.XX.YY.ZZ[4500] (476 bytes)
parsed CREATE_CHILD_SA response 0 [ SA No TSi TSr ]
selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
CHILD_SA CentralEast{8} established with SPIs cd247e35_i fef555a5_o and TS
10.64.0.0/16,10.128.0.0 === 10.0.0.0/16
connection 'CentralEast' established successfully
Yeaaaaaaaaa!
Uh... not so fast :(
[root@CentralRouter]# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
^C
--- 10.0.0.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 3052ms
[root@CentralRouter]# strongswan status
Security Associations (4 up, 0 connecting):
CentralEast[9]: ESTABLISHED 7 minutes ago,
WW.XX.YY.ZZ[WW.XX.YY.ZZ]...AA.BB.CC.DD[AA.BB.CC.DD]
CentralEast{7}: INSTALLED, TUNNEL, reqid 4, ESP in UDP SPIs: cdc46ed8_i
fd5e2ca8_o
CentralEast{7}: 10.64.0.0/16,10.128.0.0/24 === 10.0.0.0/16
however,
[root@CentralRouter]# ip route show match 10.0.0.1
default via WW.XX.YY.ZZ dev Internet proto static metric 351
[root@CentralRouter]# ip route show table 220
10.0.0.0/16 via WW.XX.YY.ZZ dev Internet proto static src 10.64.0.1
so it appears the traffic is attempting to route over my regular internet ip
link rather than the ipsec tunnel?
Not sure where to go from this point, but thanks for the help so far. Overcame
one hurdle but looks like I have another.
