[Swan] VTI issue to SRX unable to send traffic through the interface
Paul Tran
ptran6308 at gmail.com
Wed Nov 1 18:55:02 UTC 2017
RP_filter is disabled but the ipsec verify shows the same message about
disabling it still (rp_filter is not fully aware of IPsec and should be
disabled).
cat /proc/sys/net/ipv4/conf/default/rp_filter
0
Checking rp_filter [ENABLED]
/proc/sys/net/ipv4/conf/eth0/rp_filter [ENABLED]
/proc/sys/net/ipv4/conf/eth1/rp_filter [ENABLED]
rp_filter is not fully aware of IPsec and should be disabled
I see XfrmInStateMismatch incrementing when I try to send a ping from the
SRX to the Centos box via the tunnel as well as RX errors. Also the XFRM
shows 3 policies for the 10.0.0.0 to 192.168.0.0 but no policy for the
interface address. Should one exist so that I can ping the interface on the
other side which is 192.168.10.1? I did realize previously that I had the
default route with a /24 on my 0.0.0.0 so I substituted that with
192.18.50.0 which is a subnet across the tunnel since 0.0.0.0/0 drops my
connection so now all of this reflects the new changes. My pings now from
the Centos do show TX packets but I dont see them on the srx side.
vti201: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8981
inet 192.168.10.2 netmask 255.255.255.0 destination 192.168.10.2
tunnel txqueuelen 1 (IPIP Tunnel)
RX packets 0 bytes 0 (0.0 B)
RX errors 4 dropped 4 overruns 0 frame 0
TX packets 21 bytes 3654 (3.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
cat /proc/net/xfrm_stat
XfrmInError 0
XfrmInBufferError 0
XfrmInHdrError 0
XfrmInNoStates 0
XfrmInStateProtoError 0
XfrmInStateModeError 0
XfrmInStateSeqError 0
XfrmInStateExpired 0
XfrmInStateMismatch 19
But there are XFRM policies in place for
use -
src 10.0.0.0/8 dst 192.168.0.0/16 uid 0
dir out action allow index 177 priority 2864 ptype main share any
flag (0x00000000)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 0(sec), hard 0(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2017-11-01 17:54:27 use 2017-11-01 17:54:57
mark 5/0xfffffff
tmpl src 172.31.140.0 dst 102.167.4.2
proto esp spi 0x00000000(0) reqid 16389(0x00004005) mode
tunnel
level required share any
enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
src 192.168.0.0/16 dst 10.0.0.0/8 uid 0
dir fwd action allow index 194 priority 2864 ptype main share any
flag (0x00000000)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 0(sec), hard 0(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2017-11-01 17:54:27 use -
mark 5/0xfffffff
tmpl src 102.167.4.2 dst 172.31.140.0
proto esp spi 0x00000000(0) reqid 16389(0x00004005) mode
tunnel
level required share any
enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
src 192.168.0.0/16 dst 10.0.0.0/8 uid 0
dir in action allow index 184 priority 2864 ptype main share any
flag (0x00000000)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 0(sec), hard 0(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2017-11-01 17:54:27 use -
mark 5/0xfffffff
tmpl src 102.167.4.2 dst 172.31.140.0
proto esp spi 0x00000000(0) reqid 16389(0x00004005) mode
tunnel
level required share any
enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
Any suggestions on what else I might look at?
Thanks.
On Wed, Nov 1, 2017 at 10:10 AM, Paul Wouters <paul at nohats.ca> wrote:
> On Wed, 1 Nov 2017, Paul Tran wrote:
>
> Thanks for looking at things. You mentioned I would need to have a "key"
>> entry matching the mark number in your
>> config (5). I am trying to find out how I would define that key entry in
>> the config I am reading the
>> https://libreswan.org/man/ipsec.conf.5.html and not sure what I am
>> missing.
>> I also looked at other configs that people said they had working but
>> still didn't see what I needed to add.
>>
>> The information you asked about is below but I am not seeing anything
>> that points me in a direction.
>>
>>
>> IP tunnel
>>
>> vti201: ip/ip remote 102.167.4.2 local 172.31.140.0 ttl inherit key 5
>>
>
> At the end of the line you see "key 5" which matches your mark=5. So
> everything you route into this device will gain that mark value of 5,
> and then it would match the ip xfrm policy rule and get encrypted.
> (provided the source/dest also falls within that policy)
>
> Pluto ipsec.conf syntax [OK]
>> Two or more interfaces found, checking IP forwarding [OK]
>> Checking rp_filter [ENABLED]
>> /proc/sys/net/ipv4/conf/all/rp_filter [ENABLED]
>> /proc/sys/net/ipv4/conf/default/rp_filter [ENABLED]
>> /proc/sys/net/ipv4/conf/eth0/rp_filter [ENABLED]
>> /proc/sys/net/ipv4/conf/eth1/rp_filter [ENABLED]
>> /proc/sys/net/ipv4/conf/ip_vti0/rp_filter [ENABLED]
>> /proc/sys/net/ipv4/conf/tun0/rp_filter [ENABLED]
>> rp_filter is not fully aware of IPsec and should be disabled
>>
>
> I would try disabling rp_filter because it might be causing your packets
> to be dropped.
>
> I also disabled rf_filter via sysctl.conf for everything temporarily and
>> still nothing.
>>
>> ping 192.168.10.1
>> PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
>> From 192.168.10.2 icmp_seq=1 Destination Host Unreachable
>> From 192.168.10.2 icmp_seq=2 Destination Host Unreachable
>>
>> Route table shows
>> 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0
>> vti201
>> 192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0
>> vti201
>>
>> vti201: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8981
>> inet 192.168.10.2 netmask 255.255.255.0 destination 192.168.10.2
>> tunnel txqueuelen 1 (IPIP Tunnel)
>> RX packets 0 bytes 0 (0.0 B)
>> RX errors 0 dropped 0 overruns 0 frame 0
>> TX packets 0 bytes 0 (0.0 B)
>> TX errors 19 dropped 0 overruns 0 carrier 19 collisions 0
>>
>
> It shows TX errors, so it seemed to have gotten dropped. Check out:
>
> cat /proc/net/xfrm_stat
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20171101/d9fcc0d1/attachment.html>
More information about the Swan
mailing list