Page MenuHomeVyOS Platform

IPSec s2s issue in daily build - VPN traffic works, but all other traffic is broken ...
Closed, ResolvedPublic

Description

See the config :


The other end is another VyOS instance with a symmetrical config.

Traffic through the VPN works fine, and I can ping the other end. However I can't talk to the rest of the network (in this config eth0 is plugged to a classic LAN that gives internet access).

This is using vyos-999.201608290235-amd64.iso

Some debug output :

vyos@vyos:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [210/0] via 10.192.2.1, eth0
C>* 10.192.2.0/24 is directly connected, eth0
C>* 127.0.0.0/8 is directly connected, lo
C>* 172.30.1.0/30 is directly connected, eth1.1000
C>* 172.30.1.4/30 is directly connected, vti0
vyos@vyos:~$ ip xfrm policy
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir fwd priority 3075 ptype main 
	mark 0x900001/0xffffffff
	tmpl src 172.30.1.1 dst 172.30.1.2
		proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 3075 ptype main 
	mark 0x900001/0xffffffff
	tmpl src 172.30.1.1 dst 172.30.1.2
		proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 3075 ptype main 
	mark 0x900001/0xffffffff
	tmpl src 172.30.1.2 dst 172.30.1.1
		proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket out priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket out priority 0 ptype main 
src ::/0 dst ::/0 
	socket in priority 0 ptype main 
src ::/0 dst ::/0 
	socket out priority 0 ptype main 
src ::/0 dst ::/0 
	socket in priority 0 ptype main 
src ::/0 dst ::/0 
	socket out priority 0 ptype main
vyos@vyos:~$ ip xfrm state
src 172.30.1.2 dst 172.30.1.1
	proto esp spi 0xc51426a2 reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	mark 0x900001/0xffffffff
	aead rfc4106(gcm(aes)) 0x5d926a2a17022b1d5d092f37a3fe8de707d0447c 128
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 172.30.1.1 dst 172.30.1.2
	proto esp spi 0xc66e388e reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	mark 0x900001/0xffffffff
	aead rfc4106(gcm(aes)) 0x55fb1ab36cce26f388524df7adb6aa6fdc08703e 128
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
vyos@vyos:~$ sudo /usr/sbin/ipsec status
Security Associations (1 up, 0 connecting):
peer-172.30.1.1-tunnel-vti[2]: ESTABLISHED 36 minutes ago, 172.30.1.2[172.30.1.2]...172.30.1.1[172.30.1.1]
peer-172.30.1.1-tunnel-vti{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c66e388e_i c51426a2_o
peer-172.30.1.1-tunnel-vti{1}:   0.0.0.0/0 === 0.0.0.0/0

Details

Difficulty level
Easy (less than an hour)

Revisions and Commits

Event Timeline

246tnt updated the task description. (Show Details)

When looking at the state, there is a default route that got inserted in table 220 for no reason.
It seems also that only the "okey" attribute of the VTI got configured.

Adding the "ikey" and removing the spurious route seems to yield a working VPN (encrypted traffic flowing) and working network / internet access.

syncer triaged this task as High priority.Aug 31 2016, 8:45 PM
syncer added a project: VyOS 1.1.x (1.1.8).
syncer added subscribers: VyOS 1.1.x, VyOS 1.1.x (1.1.8).

Attached is the patch I'm using.

However it also requires to modify charon.conf to set install_routes = no which is global config and not per-connection.

That means you can't rely on strongswan to setup the routes for VPN with tunnel mode where you don't use VTI. I guess the best solution would be to use a custom updown script to install / remove the routes.

246tnt closed this task as Resolved by committing Restricted Diffusion Commit.Apr 25 2017, 9:13 AM
246tnt added a commit: Restricted Diffusion Commit.