Issue #3573
ike2 and transit traffic
Description
Hello,
I have strong swan 5.6.2 installed on ubuntu 18.10 according to "Roadwarrior scenario" from official website and "Route-based VPNs" from documentation (vti)
it works as expected. Separate shared vti0 interface is created on server. fine.
I also can use strong swan as client to connect to rw server with similar configuration and it also works fine!
BUT, now I want to use tunnel to pass transit traffic which not belongs to vti interfaces on server and client side. and here is problem.
for example, server vti0 has address 10.10.10.10/24 and client vti0 has 10.10.10.210/24
also client has another interface eth2 with 172.16.10.197 address
and if I use, for example command
ping -i vti0 -S 172.16.10.197 1.1.1.1
using tcpdump I can see outgoing packages on client vti0 interface, I also see packages on server side vti0 interface, but they I not seen anywhere else! they I not dropped by iptables, tcpdump -ni any imp also show only incoming from 172.16.10.197 to 1.1.1.1 and that's all...
how to make it work?
thanks in advance.
History
#1 Updated by Tobias Brunner almost 2 years ago
- Status changed from New to Feedback
I have strong swan 5.6.2 installed on ubuntu 18.10 according to "Roadwarrior scenario" from official website and "Route-based VPNs" from documentation (vti)
it works as expected. Separate shared vti0 interface is created on server. fine.I also can use strong swan as client to connect to rw server with similar configuration and it also works fine!
Why the route-based approach?
how to make it work?
You must negotiate IPsec policies between all involved parties that allow the transit traffic, the route-based approach doesn't change that. The firewall rules and forwarding must also be configured appropriately.
#2 Updated by Alex Fridman almost 2 years ago
Tobias Brunner wrote:
Why the route-based approach?
because I need to add routes and it requires gw. in case of "default" approach there is no local ip if remote side.
as an example.
server has subnet 10.10.10.0/24 for strongswan client (10.10.10.10 on server and rest for clients)
on server side there are some additional routes available via bgp, for example to net 192.168.10.0/24
I want it to be avail to client too..
so on client side (manually at the moment) I can to: ip r add 192.168.10.0/24 via 10.10.10.10 dev vti0
and this is works ONLY if source ip is from 10.10.10.0/24!!!
in server configuration I have
leftsubnet=0.0.0.0/0
rightsubnet=192.168.0.0/24,172.16.0.0/16,10.0.0.0/8
ipsec statusall shows on server side for connected client
0.0.0.0/0 === 10.0.0.0/8 172.16.0.0/16 192.168.0.0/24
and
10.0.0.0/8 172.16.0.0/16 192.168.0.0/24 === 0.0.0.0/0
on client side
You must negotiate IPsec policies between all involved parties that allow the transit traffic, the route-based approach doesn't change that. The firewall rules and forwarding must also be configured appropriately.
ip xfrm policy shows policies on client side like this
src 192.168.0.0/24 dst 0.0.0.0/0
dir out priority 387711 ptype main
mark 0x2a/0xffffffff
tmpl src <clientIP> dst <serverIP>
proto esp spi 0xca76e27d reqid 1 mode tunnel
src 0.0.0.0/0 dst 192.168.0.0/24
dir fwd priority 387711 ptype main
mark 0x2a/0xffffffff
tmpl src <serverIP> dst <clientIP>
proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 192.168.0.0/24
dir in priority 387711 ptype main
mark 0x2a/0xffffffff
tmpl src <serverIP> dst <clientIP>
proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 0.0.0.0/0
dir out priority 391807 ptype main
mark 0x2a/0xffffffff
tmpl src <clientIP> dst <serverIP>
proto esp spi 0xca76e27d reqid 1 mode tunnel
src 0.0.0.0/0 dst 172.16.0.0/16
dir fwd priority 391807 ptype main
mark 0x2a/0xffffffff
tmpl src <serverIP> dst <clientIP>
proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 172.16.0.0/16
dir in priority 391807 ptype main
mark 0x2a/0xffffffff
tmpl src <serverIP> dst <clientIP>
proto esp reqid 1 mode tunnel
src 10.0.0.0/8 dst 0.0.0.0/0
dir out priority 395903 ptype main
mark 0x2a/0xffffffff
tmpl src <clientIP> dst <serverIP>
proto esp spi 0xca76e27d reqid 1 mode tunnel
src 0.0.0.0/0 dst 10.0.0.0/8
dir fwd priority 395903 ptype main
mark 0x2a/0xffffffff
tmpl src <serverIP> dst <clientIP>
proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 10.0.0.0/8
dir in priority 395903 ptype main
mark 0x2a/0xffffffff
tmpl src <serverIP> dst <clientIP>
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
similar (versus) on server side
what additional configuration to iptables required?
iptables -A FORWARD -j ACCEPT
exists
net.ipv4.ip_forward=1 also exists in other cease it will not word at all...
#3 Updated by Tobias Brunner almost 2 years ago
what additional configuration to iptables required?
iptables -A FORWARD -j ACCEPT
Depends on your actual config.
net.ipv4.ip_forward=1 also exists in other cease it will not word at all...
Could be net.ipv4.conf.<all|interface>.rp_filter.
#4 Updated by Alex Fridman over 1 year ago
Tobias Brunner wrote:
Depends on your actual config.
is there any working server config suitable for:
- road warrior (clients mostly mobile phones)
- strong swan clients to run bgp and make transit traffic of non local nets (+ local) of server and client
?
#5 Updated by Tobias Brunner over 1 year ago
is there any working server config suitable for:
- road warrior (clients mostly mobile phones)
- strong swan clients to run bgp and make transit traffic of non local nets (+ local) of server and client
?
If you don't find one on UsableExamples or ConfigurationExamples or elsewhere on the wiki or the web then I guess you have to actually do this yourself (or hire somebody do to it for you).