3

I have two Debian machines, one set up as a proxy, which I'll refer to as proxy1 and another set up as a router, which I'll refer to as router. My goal is to DNAT packets coming in from the WAN on proxy1 via an OpenVPN tunnel to the router. The router and proxy1 both have access to the internet and have different WAN IPs, they're separate machines.

I have the following rules on proxy1:

iptables -t nat -A PREROUTING -m tcp -p tcp --dport 80 -j DNAT --to-destination 10.0.0.2:80
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
ip route add 10.0.0.2/32 dev tun0

When running "tcpdump -s 0 -w tcpdump.log -i any" on both proxy1 and the router, I can see the packet come in from the WAN, and the DNAT change the destination of the packet on proxy1, but on the router, the packet doesn't arrive.

The strangest thing about this problem is that if I change my MASQUERADE rule to:

iptables -t nat -A POSTROUTING j MASQUERADE 

Then the DNAT works, and the packet is seen on the router. But masquerading changes the source address of the packet, so the router doesn't know the ultimate source IP. I can't figure out why the packet would make it to the router when the source address is modified to 10.0.1.2 but not make it to the router when the source address is preserved?

Here is info about the openvpn tunnel setup as well:

verb 3
user nobody
group nogroup
dev tun0
proto udp4
server 10.0.1.0 255.255.255.248
topology subnet
client-to-client
keepalive 10 120
persist-tun
persist-key
push "dhcp-option DNS 10.0.1.1"
push "dhcp-option DOMAIN lan"
push "persist-tun"
push "persist-key"

Proxy Info:

Debian GNU/Linux 8 (jessie)

kernel version: Linux 3.16.0-4-amd64 x86_64

Proxy IP: 202.89.75.110

Running "ip route get 10.0.0.2" on proxy1 returns:

10.0.0.2 dev tun0  src 10.0.1.2
    cache

Output of "ip link; ip -4 address; ip -4 route; ip -4 rule" run on proxy1:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:16:3c:95:70:75 brd ff:ff:ff:ff:ff:ff
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100
    link/none
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet x.x.x.x/25 brd x.x.x.127 scope global eth0
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    inet 10.0.1.2/29 brd 10.0.1.7 scope global tun0
       valid_lft forever preferred_lft forever
default via x.x.x.1 dev eth0
10.0.0.2 dev tun0  scope link
10.0.1.0/29 dev tun0  proto kernel  scope link  src 10.0.1.2
x.x.x.0/25 dev eth0  proto kernel  scope link  src x.x.x.x
0:      from all lookup local
32765:  from all fwmark 0x65 lookup 101
32766:  from all lookup main
32767:  from all lookup default

Here is some info about the router:

Debian GNU/Linux 10 (buster)

kernel version: Linux 4.19.0-6-amd64 x86_64

Router IP: 71.115.98.227

Output of "ip link; ip -4 address; ip -4 route; ip -4 rule" run on the router:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 70:85:c2:d5:84:96 brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 70:85:c2:d5:84:94 brd ff:ff:ff:ff:ff:ff
4: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100
    link/none
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 10.0.0.1/24 brd 10.0.0.255 scope global enp2s0
       valid_lft forever preferred_lft forever
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 71.115.98.227/21 brd 71.115.105.255 scope global dynamic eno1
       valid_lft 38916sec preferred_lft 38916sec
4: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    inet 10.0.1.1/29 brd 10.0.1.7 scope global tun1
       valid_lft forever preferred_lft forever
default via 71.115.98.1 dev eno1
10.0.0.0/24 dev enp2s0 proto kernel scope link src 10.0.0.1
10.0.1.0/29 dev tun1 proto kernel scope link src 10.0.1.1
71.115.98.0/21 dev eno1 proto kernel scope link src 71.115.98.227
0:      from all lookup local
32765:  from all fwmark 0x65 lookup 101
32766:  from all lookup main
32767:  from all lookup default

Output of "ip route list table 101" on the router:

default via 10.0.1.2 dev tun1
New contributor
mcmsweet is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • Just a remark: tcpdump listens on the interface of each machine. iptables is filtering package AFTER the interface receives the packages. Just wanted to make this clear that regardless the iptables rules, you should see the packages coming/going from the interfaces – ebal Nov 8 at 18:26
  • @A.B Hi A.B thanks for continuing here! Sorry for the delay - I have updated my question with info about the router as requested. Please let me know if anything else is needed! I am only wanting to forward TCP packets but I want to forward them over the VPN tunnel on UDP. – mcmsweet Nov 11 at 19:26
  • @A.B I actually added those rules back myself. I deleted them for the sake of debugging since the packets aren't reaching the router at all. I can once again remove or update the topic with the ip rule, ip route for routing table, mangle restore mark and mangle mark rules depending which direction you'd like to go. tcpdump still does not show packets arriving at the router with the rules configured or not. The packets are DNAT'd at the router to a server the same rules are applied there for routing. – mcmsweet Nov 12 at 1:33
  • @A.B The server 10.0.0.2 should be able to access the internet via the router as well unfortunately. – mcmsweet 2 days ago
  • Well I thought I got a solution, but I tested it with openvpn in mode p2p (the default) rather than server mode. Switching to server mode (incl. generating certs...) just revealed the same problem you have. What could perhaps be solved using CONNMARK on the linux routing stack might have no equivalent in the internal openvpn routing "stack" (see directives like iroute ...). So I give up. Maybe somebody will know better (how to route other networks coming from the openvpn client rather than the openvpn server). To me the issue is about openvpn itself rather than anything else. – A.B yesterday

Your Answer

mcmsweet is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.