Điểm:0

site-to-site VPN route traffic through VPN tunnel

lá cờ ru
Cal

Short version: in a site-to-site VPN setup with Strongswan on both sides, how to route particular traffic via the VPN tunnel?

Long version:

We have two Linux (ubuntu 20.04) in AWS, both installed with Strongswan VPN, and a VPN tunnel has been established.

IP 172.31.0.151                      IP 10.0.0.14 
Server 1        <===VPN tunnel===>   Server 2

As expected, they can ping each other, tcpdump will display correct private IP addresses for the ping.

The content of /etc/ipsec.conf of Server 2 (Server 1 ipsec.conf is almost identical, just swapping left/right values):

# basic configuration
config setup
# Add connections here.
conn %default
 ikelifetime=28800s
 lifetime=3600s
#rekeymargin= You choose; must match other side
 keyingtries=%forever
 keyexchange=ikev2
 authby=secret
 mobike=no


conn vpn-test
# private ip
 left=10.0.0.14

# vpc cidr
 leftsubnet=10.0.0.0/24

# elastic ip
 leftid=18.999.999.999

# private ip
 leftsourceip=10.0.0.14

# public/elastic ip
 right=18.888.888.888

# subnet/VPC cidr
 rightsubnet=172.31.0.0/16,2.2.2.2/32

 auto=start
 type=tunnel
 ike=aes256-sha1-modp1024!
 esp=aes256-sha1!
 dpddelay=30s
 dpdtimeout=120s
 dpdaction=restart
# Add connections here.

Goal: if from Server 2 we need to access a "dummy" IP address in Server 1's network, for example, we want to ping 2.2.2.2 and send the ping request over the VPN tunnel, instead of going out of the Server 2's actual network interface and into the internet.

With the 2.2.2.2/32 in both configuration, left/rightsubnet respectively, it still doesn't work.

Mehod 1 we tried: ip route add

The Strongswan does not create a VPN network interface, an ip a command gives the two default network interfaces in the Ubuntu:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0e:ac:45:e9:76:60 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.14/28 brd 10.0.0.15 scope global dynamic ens5
       valid_lft 3576sec preferred_lft 3576sec
    inet6 fe80::cac:45ff:fee9:7660/64 scope link
       valid_lft forever preferred_lft forever

So to use ip route add command to route traffic will not work here.

Method 2: iptables

The other method we tried is to use iptables to do DNAT, when destination is 2.2.2.2, route it to Server 1's ip address of 172.31.0.151, however DNAT will change the destination, therefore on Server 1 we will observe packets with destination of 172.31.0.151, instead of 2.2.2.2, and unable to NAT it accordingly. So iptables doesn't solve this problem either.

Being new to this field I don't know if it should be in Strongswan configuration or Linux routing or something else. How can we approach the issue?

Thank you for your time.

Điểm:0
lá cờ ru
Cal

Để trả lời câu hỏi của riêng tôi, khi tôi thay thế dòng này

 rightsubnet=172.31.0.0/16,2.2.2.2/32

Với

 rightsubnet=2.2.2.2

Nó hoạt động. Từ Serer 2, tôi có thể ping 2.2.2.2 và Máy chủ 1 sẽ nhận được.

Cả hai máy chủ cần phải được sửa đổi cho phù hợp.

Cảm ơn bạn.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.