[Swan] Cannot ping the other end

Xinwei Hong xhong at skytap.com
Fri Jan 20 00:00:08 UTC 2017


Thank you very much.
After I enable IP forwarding and add sourceip, things are working now. The
send_redirects/accept_redirects seems does not matter. Regarding sourceip,
you mentioned.
"Of course, if the IPsec server is just routing the entire /24 elsewhere,
this does not apply."
In my case, I do want route the entire /24 to remote. Can you confirm,
sourceip is required even in this case?
Last time, when I set up VTI support, sourceip seems was not required.


I did not do -up multiple times. I did ipsec start/stop.

Thanks,
Xinwei



On Thu, Jan 19, 2017 at 2:50 PM, Paul Wouters <paul at nohats.ca> wrote:

> On Thu, 19 Jan 2017, Xinwei Hong wrote:
>
> I'm trying to set up a VPN tunnel between two networks.
>> "my_vpn": 10.0.1.0/24===10.2.128.171<10.2.128.171>..10.2.128.170<10.2.
>> 128.170>===10.0.2.0/24;
>>
>
> conn my_vpn
>>     left=10.2.128.171
>>     right=10.2.128.170
>>     leftsubnet=10.0.1.0/24
>>     rightsubnet=10.0.2.0/24
>>
>
> You mighy want to add leftsourceip=10.0.1.1 and rightsourceip=10.0.2.1
> That is, leftsourceip is the IP from the 10.0.1.0/24 that is configured on
> the IPsec machine's internal ethernet interface. Of course, if the IPsec
> server is just routing the entire /24 elsewhere, this does not apply.
>
> 000 Total IPsec connections: loaded 1, active 1
>> 000
>> 000 State Information: DDoS cookies not required, Accepting new IKE
>> connections
>> 000 IKE SAs: total(2), half-open(0), open(0), authenticated(2),
>> anonymous(0)
>> 000 IPsec SAs: total(2), authenticated(2), anonymous(0)
>> 000
>> 000 #4: "my_vpn":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
>> EVENT_SA_REPLACE in 27060s; newest IPSEC; eroute owner; isakmp#1; idle;
>> import:admin initiate
>> 000 #4: "my_vpn" esp.4b1111f5 at 10.2.128.170 esp.91c9eaa8 at 10.2.128.171
>> tun.0 at 10.2.128.170 tun.0 at 10.2.128.171 ref=0 refhim=0 Traffic: ESPin=0B
>> ESPout=0B! ESPmax=4194303B
>> 000 #1: "my_vpn":500 STATE_MAIN_I4 (ISAKMP SA established);
>> EVENT_SA_REPLACE in 1619s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0);
>> idle; import:admin initiate
>> 000 #3: "my_vpn":500 STATE_QUICK_R2 (IPsec SA established);
>> EVENT_SA_REPLACE in 27538s; isakmp#2; idle; import:not set
>> 000 #3: "my_vpn" esp.d171d1be at 10.2.128.170 esp.b441013 at 10.2.128.171
>> tun.0 at 10.2.128.170 tun.0 at 10.2.128.171 ref=0 refhim=0 Traffic: ESPin=0B
>> ESPout=0B! ESPmax=4194303B
>> 000 #2: "my_vpn":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
>> EVENT_SA_REPLACE in 2338s; lastdpd=-1s(seq in:0 out:0); idle; import:not set
>>
>
> Looks fine, there are a few "dying" old tunnels there. You probably ran
> --up a few times?
>
> 000 Bare Shunt list:
>> 000
>>
>> “ipsec verify” shows some error:
>> Verifying installed system and configuration files
>>
>> Version check and ipsec on-path                   [OK]
>> Libreswan 3.18 (netkey) on 4.4.0-31-generic
>> Checking for IPsec support in kernel               [OK]
>>  NETKEY: Testing XFRM related proc values
>>          ICMP default/send_redirects               [NOT DISABLED]
>>
>
> Really just disabled those in /etc/sysctl.*
>
>   Disable /proc/sys/net/ipv4/conf/*/send_redirects or NETKEY will act on
>> or cause sending of bogus ICMP redirects!
>>
>>          ICMP default/accept_redirects             [NOT DISABLED]
>>
>
> Really just disabled those in /etc/sysctl.*
>
>   Disable /proc/sys/net/ipv4/conf/*/accept_redirects or NETKEY will act
>> on or cause sending of bogus ICMP redirects!
>>
>
> Really just disabled those in /etc/sysctl.*
>
>>
>>          XFRM larval drop                         [OK]
>> Pluto ipsec.conf syntax                           [OK]
>> Hardware random device                             [N/A]
>> Two or more interfaces found, checking IP forwarding [FAILED]
>>
>
> Forwarding is disabled, you might want it enabled for traffic to move
> between eth0 and eth1, although it is possible you have done that
> using iptables rules instead?
>
> 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/eth2/rp_filter           [ENABLED]
>>  /proc/sys/net/ipv4/conf/ip_vti0/rp_filter         [ENABLED]
>>  /proc/sys/net/ipv4/conf/lo/rp_filter             [ENABLED]
>>   rp_filter is not fully aware of IPsec and should be disabled
>>
>
> the networks on each side is on eth3, for which I have changed rp_filter
>> to 0.
>>
>
> I would really disable it on all interfaces. Or at the very least enable
> martian logging, so you know that rp_filter is being hit and you need to
> fix it.
>
>
> I have:
>> local host 10.0.1.2 (added route to 10.0.2.0/24 via 10.0.1.1 on this
>> eth3)
>> local vpn router: has 10.0.1.1 on eth3.
>>             10.2.128.171 on eth1
>> remote vpn router: 10.0.2.1 on eth3
>>             10.2.128.170 on eth1
>> remote host: 10.0.2.2 (added route to 10.0.1.0/24 via 10.0.2.1 on eth3)
>>
>> when I try to ping from local host to 10.0.2.2, traffic only reach local
>> vpn router on eth3.
>>
>
> Post likely because the ping packet it generated on the ipsec gw itself
> without the *sourceip= entries used the "nearest IP", so your ping
> would have source ip 10.2.128.171 and destination ip 10.0.2.2, which
> DOES NOT match any tunnel because your tunnel is for 10.0.1.0/24 <->
> 10.0.2.0/24. See the above leftsourceip/rightsourceip options.
>
> "ipsec whack --trafficstatus" got:
>>
>> 006 #4: "my_vpn", type=ESP, add_time=1484863659, inBytes=0, outBytes=0,
>> id='10.2.128.170'
>>
>> 006 #3: "my_vpn", type=ESP, add_time=1484863655, inBytes=0, outBytes=0,
>> id='10.2.128.170'
>>
>
> This shows the tunnel is up (but two of them?) but no traffic matched
> and 0 traffic was encrypted/decrypted.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20170119/ba901594/attachment-0001.html>


More information about the Swan mailing list