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 <[email protected]> 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" [email protected] [email protected] >> [email protected] [email protected] 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" [email protected] [email protected] >> [email protected] [email protected] 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 >
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
