Project

General

Profile

Issue #3573

ike2 and transit traffic

Added by Alex Fridman about 1 month ago. Updated 20 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.6.2
Resolution:

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 about 1 month 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 about 1 month 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 about 1 month 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 20 days 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 20 days 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).

Also available in: Atom PDF