[GH-ISSUE #207] VPN don't work with --net=host option #193

Closed
opened 2026-03-02 07:44:39 +03:00 by kerem · 2 comments
Owner

Originally created by @BulatSaif on GitHub (Oct 16, 2020).
Original GitHub issue: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/207

Checklist
Similar issues:
https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/70
https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/154
https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/183
https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/200

Describe the issue
I found several GitHub issues where users wanted to route traffic to another docker container running on the same machine as the VPN container but due Docker's network isolation it is very complicated.
The --net=host option can be a simple solution for this issue.
I tested it. And it works, I can ping containers network from remote and ping remote host from the container.

But main VPN functionality is broken. I guess somewhere MASQUERADE is absent and I can not access to the internet form remote host.

To Reproduce
Steps to reproduce the behavior:

  1. Run docker-compose:
services:
  vpn:
    image: hwdsl2/ipsec-vpn-server
    container_name: ipsec-vpn-server
    restart: always
    environment:
      - VPN_IPSEC_PSK=psk
      - VPN_USER=user
      - VPN_PASSWORD=password
    ports:
      - 500:500/udp
      - 4500:4500/udp
    privileged: true
    network_mode: host
  1. Connect to vpn.

  2. Ping container network on vpn server (run some container with network 172.18.0.1 on vpn server, check what you don't have same network in you local pc).

ping 172.18.0.1 -c1
PING 172.18.0.1 (172.18.0.1) 56(84) bytes of data.
64 bytes from 172.18.0.1: icmp_seq=1 ttl=64 time=80.9 ms

--- 172.18.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 80.944/80.944/80.944/0.000 ms

It works, great!

  1. ping 8.8.8.8
    It does not work. I can see in tcpdump that packet is send from vpn server to 8.8.8.8 but I guess the source address is not correct so I didn't receive reply.

Expected behavior
Docker container and vpn works with --net=host option.

Logs
No error in logs.

Server (please complete the following information)

  • Docker host OS: Ubuntu 20.04
  • Hosting provider: AWS

Client (please complete the following information)

  • Device: PC
  • OS: Ubuntu
  • VPN mode: IPsec/L2TP

Additional context

# ip a
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 0a:ee:ba:da:41:90 brd ff:ff:ff:ff:ff:ff
    inet 172.31.36.255/20 brd 172.31.47.255 scope global dynamic ens5
       valid_lft 2222sec preferred_lft 2222sec
    inet6 fe80::8ee:baff:feda:4190/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:23:8d:53:d6 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
4: br-fe851b1a50b9: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:1b:74:00:6f brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-fe851b1a50b9
       valid_lft forever preferred_lft forever
    inet6 fe80::42:1bff:fe74:6f/64 scope link 
       valid_lft forever preferred_lft forever
14: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 192.168.42.1 peer 192.168.42.10/32 scope global ppp0
       valid_lft forever preferred_lft forever
16: ppp2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 192.168.42.1 peer 192.168.42.12/32 scope global ppp2
       valid_lft forever preferred_lft forever
20: br-55f40ed53bb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:13:9e:26:e0 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-55f40ed53bb0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:13ff:fe9e:26e0/64 scope link 
       valid_lft forever preferred_lft forever
22: veth8067ad3@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-55f40ed53bb0 state UP group default 
    link/ether 32:aa:a2:14:3d:23 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::30aa:a2ff:fe14:3d23/64 scope link 
       valid_lft forever preferred_lft forever


# ip r
default via 172.31.32.1 dev ens5 proto dhcp src 172.31.36.255 metric 100 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.18.0.0/16 dev br-55f40ed53bb0 proto kernel scope link src 172.18.0.1 
172.19.0.0/16 dev br-fe851b1a50b9 proto kernel scope link src 172.19.0.1 linkdown 
172.31.32.0/20 dev ens5 proto kernel scope link src 172.31.36.255 
172.31.32.1 dev ens5 proto dhcp scope link src 172.31.36.255 metric 100 
192.168.42.10 dev ppp0 proto kernel scope link src 192.168.42.1 
192.168.42.12 dev ppp2 proto kernel scope link src 192.168.42.1 

Originally created by @BulatSaif on GitHub (Oct 16, 2020). Original GitHub issue: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/207 **Checklist** Similar issues: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/70 https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/154 https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/183 https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/200 **Describe the issue** I found several GitHub issues where users wanted to route traffic to another docker container running on the same machine as the VPN container but due Docker's network isolation it is very complicated. The `--net=host` option can be a simple solution for this issue. I tested it. And it works, I can ping containers network from remote and ping remote host from the container. But main VPN functionality is broken. I guess somewhere `MASQUERADE` is absent and I can not access to the internet form remote host. **To Reproduce** Steps to reproduce the behavior: 1. Run docker-compose: ``` services: vpn: image: hwdsl2/ipsec-vpn-server container_name: ipsec-vpn-server restart: always environment: - VPN_IPSEC_PSK=psk - VPN_USER=user - VPN_PASSWORD=password ports: - 500:500/udp - 4500:4500/udp privileged: true network_mode: host ``` 2. Connect to vpn. 3. Ping container network on vpn server (run some container with network 172.18.0.1 on vpn server, check what you don't have same network in you local pc). ``` ping 172.18.0.1 -c1 PING 172.18.0.1 (172.18.0.1) 56(84) bytes of data. 64 bytes from 172.18.0.1: icmp_seq=1 ttl=64 time=80.9 ms --- 172.18.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 80.944/80.944/80.944/0.000 ms ``` It works, great! 4. ping 8.8.8.8 It does not work. I can see in `tcpdump` that packet is send from vpn server to 8.8.8.8 but I guess the source address is not correct so I didn't receive reply. **Expected behavior** Docker container and vpn works with `--net=host` option. **Logs** No error in logs. **Server (please complete the following information)** - Docker host OS: Ubuntu 20.04 - Hosting provider: AWS **Client (please complete the following information)** - Device: PC - OS: Ubuntu - VPN mode: IPsec/L2TP **Additional context** ``` # ip a 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 0a:ee:ba:da:41:90 brd ff:ff:ff:ff:ff:ff inet 172.31.36.255/20 brd 172.31.47.255 scope global dynamic ens5 valid_lft 2222sec preferred_lft 2222sec inet6 fe80::8ee:baff:feda:4190/64 scope link valid_lft forever preferred_lft forever 3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:23:8d:53:d6 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever 4: br-fe851b1a50b9: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:1b:74:00:6f brd ff:ff:ff:ff:ff:ff inet 172.19.0.1/16 brd 172.19.255.255 scope global br-fe851b1a50b9 valid_lft forever preferred_lft forever inet6 fe80::42:1bff:fe74:6f/64 scope link valid_lft forever preferred_lft forever 14: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 3 link/ppp inet 192.168.42.1 peer 192.168.42.10/32 scope global ppp0 valid_lft forever preferred_lft forever 16: ppp2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 3 link/ppp inet 192.168.42.1 peer 192.168.42.12/32 scope global ppp2 valid_lft forever preferred_lft forever 20: br-55f40ed53bb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:42:13:9e:26:e0 brd ff:ff:ff:ff:ff:ff inet 172.18.0.1/16 brd 172.18.255.255 scope global br-55f40ed53bb0 valid_lft forever preferred_lft forever inet6 fe80::42:13ff:fe9e:26e0/64 scope link valid_lft forever preferred_lft forever 22: veth8067ad3@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-55f40ed53bb0 state UP group default link/ether 32:aa:a2:14:3d:23 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 fe80::30aa:a2ff:fe14:3d23/64 scope link valid_lft forever preferred_lft forever # ip r default via 172.31.32.1 dev ens5 proto dhcp src 172.31.36.255 metric 100 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 172.18.0.0/16 dev br-55f40ed53bb0 proto kernel scope link src 172.18.0.1 172.19.0.0/16 dev br-fe851b1a50b9 proto kernel scope link src 172.19.0.1 linkdown 172.31.32.0/20 dev ens5 proto kernel scope link src 172.31.36.255 172.31.32.1 dev ens5 proto dhcp scope link src 172.31.36.255 metric 100 192.168.42.10 dev ppp0 proto kernel scope link src 192.168.42.1 192.168.42.12 dev ppp2 proto kernel scope link src 192.168.42.1 ```
kerem closed this issue 2026-03-02 07:44:40 +03:00
Author
Owner

@BulatSaif commented on GitHub (Oct 16, 2020):

I found problem, I have different interface name, ens5 on host and eth0 in docker
Workaround:

version: '3.5'

services:
  vpn:
    image: hwdsl2/ipsec-vpn-server
    container_name: ipsec-vpn-server
    restart: always
    environment:
      - VPN_IPSEC_PSK=psk
      - VPN_USER=user
      - VPN_PASSWORD=password
    ports:
      - 500:500/udp
      - 4500:4500/udp
    privileged: true
    network_mode: host
    command: bash -c 'sed -i 's/eth0/ens5/' /opt/src/run.sh; sed -i 's/eth+/ens+/' /opt/src/run.sh; /opt/src/run.sh'

Is it possible to add support of --net=host in /opt/src/run.sh?

<!-- gh-comment-id:710680731 --> @BulatSaif commented on GitHub (Oct 16, 2020): I found problem, I have different interface name, `ens5` on host and `eth0` in docker Workaround: ``` version: '3.5' services: vpn: image: hwdsl2/ipsec-vpn-server container_name: ipsec-vpn-server restart: always environment: - VPN_IPSEC_PSK=psk - VPN_USER=user - VPN_PASSWORD=password ports: - 500:500/udp - 4500:4500/udp privileged: true network_mode: host command: bash -c 'sed -i 's/eth0/ens5/' /opt/src/run.sh; sed -i 's/eth+/ens+/' /opt/src/run.sh; /opt/src/run.sh' ``` Is it possible to add support of `--net=host` in `/opt/src/run.sh`?
Author
Owner

@Smosia commented on GitHub (Jan 4, 2022):

Is it possible to add support of nftables here? github.com/hwdsl2/docker-ipsec-vpn-server@b01c7d8951/run.sh (L479)
Looks like nftables become more and more popular service.

Maybe you can add new container parameter to choose between iptables and nftables?
iptables-translate utility may help to convert rules.
Thank you!

<!-- gh-comment-id:1005089083 --> @Smosia commented on GitHub (Jan 4, 2022): Is it possible to add support of nftables here? https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/b01c7d8951cc9c797791b96ff1bfd46ac336862b/run.sh#L479 Looks like nftables become more and more popular service. Maybe you can add new container parameter to choose between iptables and nftables? iptables-translate utility may help to convert rules. Thank you!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/docker-ipsec-vpn-server#193
No description provided.