Join Log in
Score:0
avatar Server

Mirror incoming traffic on specific port to another IP, using my IPSec strongswan tunnel

za flag
Theo

I want to internally publish an SMTP server (IP 10.0.0.10) that is behind a VPN tunnel on my internal server (192.168.0.12) using strongswan. My strongswan is running within a docker container.

For this I want my internal server 192.168.0.12 to listen to its 25 port and to forward the traffic to the tunneled server on the same port 10.0.0.10:25.

So far I tried using iptables, but without success.

net.ipv4.ip_forward is enabled on both the host and the docker container!

my iptables-save on 192.168.0.12 after strongswan is connected to the tunnel: (and yes I can ping the 10.0.0.10 from 192.168.0.12)

# Generated by iptables-save v1.8.4 on Fri Jul 23 09:55:05 2021
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -s 10.0.0.0/16 -d 192.168.0.10/32 -i eth0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A OUTPUT -s 192.168.0.10/32 -d 10.0.0.0/16 -o eth0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
COMMIT
# Completed on Fri Jul 23 09:55:05 2021
# Generated by iptables-save v1.8.4 on Fri Jul 23 09:55:05 2021
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [2:1600]
:POSTROUTING ACCEPT [2:1600]
:DOCKER_OUTPUT - [0:0]
:DOCKER_POSTROUTING - [0:0]
-A OUTPUT -d 127.0.0.11/32 -j DOCKER_OUTPUT
-A POSTROUTING -d 127.0.0.11/32 -j DOCKER_POSTROUTING
-A DOCKER_OUTPUT -d 127.0.0.11/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.11:45165
-A DOCKER_OUTPUT -d 127.0.0.11/32 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.11:53306
-A DOCKER_POSTROUTING -s 127.0.0.11/32 -p tcp -m tcp --sport 45165 -j SNAT --to-source :53
-A DOCKER_POSTROUTING -s 127.0.0.11/32 -p udp -m udp --sport 53306 -j SNAT --to-source :53
COMMIT

command ip r output:

default via 192.168.16.1 dev eth0
192.168.16.0/20 dev eth0 proto kernel scope link src 192.168.16.10 # this is a docker internal network for my services
192.168.0.10/30 dev eth1 proto kernel scope link src 192.168.0.12

I tried various commands like these:

iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 10.0.0.10:25
iptables -t nat -A POSTROUTING -p tcp -d 10.0.0.10 --dport 25 -j SNAT --to-source 192.168.0.12

but without success.

I cannot provide any info on the ip r of the host nor the iptables-save.

What am I doing wrong?

190
1 + 9
Tom Yan avatar
in flag
Tom Yan
Please provide the output of the following commands on *both the container host and the container*: `ip r` (and maybe also `ip a`), `iptables-save` and `sysctl net.ipv4.ip_forward`.
0
Reply
za flag
Theo
@TomYan added all information that I could gather, I am restricted on the host machine. I managed to ask the host whether IP forwarding was enabled, and it is enabled.
0
Reply
Tom Yan avatar
in flag
Tom Yan
I don't understand. You don't have control over `my internal server (192.168.0.10)`? Or is it actually another container? (Running in parallel to the Strongswan one, which is `192.168.0.12`?)
0
Reply
Tom Yan avatar
in flag
Tom Yan
Also the `ip r` output seems off as well. `192.168.0.12` isn't even a valid host address with `/30` (since it would be the subnet ID).
0
Reply
za flag
Theo
@TomYan thank you for your help, I updated the IPs so they are correct now. I don't have control over the host that is running the docker container. I only control the docker container itself `192.168.0.12`. I am sure the issue is not with the host, but with the `iptables` configuration inside the docker container.
0
Reply
Tom Yan avatar
in flag
Tom Yan
The problem is, who / which host(s) will the server/container be serving / forwarding for? And how was this address on this `eth1` configured? DHCP? Static? (By you?) As I said, the output of `ip r` does not really make sense. Is it even a "real" paste? (Or is it some "write/type it down"?) And is this "docker internal network" (`eth0`) supposed to be irrelevant to your goal/clients here?
0
Reply
Tom Yan avatar
in flag
Tom Yan
Also, if this server/forwarder here is the same container as the strongswan one, where's even the route to the tunnel? Have you configured policy routing or what?
0
Reply
cn flag
ecdsa
How do you test this? By connecting to port 25 of the host? Or from another container? Either way, do these packets actually enter the container and hit the NAT rules?
0
Reply
za flag
Theo
@ecdsa I test this with `telnet 10.0.0.10 25` on the `strongswan container` and the goal is to `telnet strongswan 25` assuming that the container name is `strongswan`
0
Reply
Score:0
avatar Server
za flag
Theo

I solved my issue using traefik.

I installed traefik on the host (192.168.0.12) that has the strongswan tunnel and used a TCP router to forward all traffic to the tunnel.

traefik installation:

wget -O /traefik.tar.gz https://github.com/traefik/traefik/releases/download/v2.4.12/traefik_v2.4.12_linux_amd64.tar.gz \
    && tar -zxvf /traefik.tar.gz \
    && ln -s /traefik /usr/bin/traefik

traefik.yaml:

entryPoints:
  smtp:
    address: ":1025"

accessLog: {}

providers:
  file:
    directory: /traefik-conf/dynamic/
    watch: true

api:
  dashboard: true
  insecure: true

my /traefik-conf/dynamic/dynamic.yaml:

tcp:
  routers:
    smtp-router:
      rule: "HostSNI(`*`)"
      entryPoints:
        - smtp
      service: smtp-service

  services:
    smtp-service:
      loadBalancer:
        servers:
          - address: 10.0.0.10:25

Run traefik (I don't know how to properly run it as a background daemon):

traefik --configfile /traefik-conf/traefik.yml &

Now I can connect to the tunneled smtp server from everywhere inside my network using 192.168.0.12:1025.

I created an example using docker over here on github

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.