On Wed, 11 Mar 2020, Reuben Farrelly wrote:
As it turns out, this error was caused by missing bits of kernel support for
the use of 'ip rule'.
So things are looking better now:
I had to manually set an IP address on the ipsec1 interface, but it still
doesn't work.
Yes, in the next release, leftinterface-ip= should work for that.
lightning ~ # ip -d link show dev ipsec1
5: ipsec1@eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/none promiscuity 0 minmtu 68 maxmtu 65535
xfrm if_id 0x1 addrgenmode random numtxqueues 1 numrxqueues 1
gso_max_size 65536 gso_max_segs 65535
lightning ~ # ip -s link show dev ipsec1
5: ipsec1@eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/none
RX: bytes packets errors dropped overrun mcast
1130640 13460 0 0 0 0
TX: bytes packets errors dropped carrier collsns
170268 2027 0 12 0 0
lightning ~ #
So it does see packets both ways. What does ipsec trafficstatus say? Did
it receive encrypted packets and send encrypted packets too?
lightning ~ # ip route
default via 172.105.178.1 dev eth0 metric 2
172.105.178.0/24 dev eth0 proto kernel scope link src 172.105.178.21
192.168.6.0/30 dev ipsec1 proto kernel scope link src 192.168.6.1
Hmm that looks okay.
Looks a lot like IPSec is happy but the routing/interface side of things is
not.
Do you see an increase in numbers in /proc/net/xfrm_stat ?
is rp_filter disabled? and ip_forwarding enabled?
I've made no changes at all on the Cisco and I assume that I won't need to do
so for this to work given it did previously with vti.
Correct. Nothing different is negotiated. It is all local changes only.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
