New iptables NAT produces Error 400 Bad Request for Other HTTP Requests

Question

All:

Recently, I added several new iptables (RE: code snippet below) rules to route traffic through my VPN (0x1000/0x1000) for a specific destination (172.67.168.48) over port 443. The new rules NAT over the VPN as desired, but they've created an undesired effect causing other HTTP requests, unrelated to the aforementioned destination, to produce an error response 400 Bad Request.

# Create the RPDB rules
ip rule add from 0/0 fwmark "0x1000/0x1000" table ovpnc1 prio 9993        # VPN 1 fwmark

iptables -t mangle -A PREROUTING -i br0 -p tcp -d 172.67.168.48 --dport 443 -j MARK --set-mark 0x1000/0x1000
iptables -t nat -A PREROUTING -i br0 -p tcp -m mark --mark 0x1000/0x1000 -j DNAT --to-destination 172.67.168.48:443

Any idea why other HTTP requests would be affected (400 Bad Request) by the new NAT rules when the destination address and port are clearly specified?

Thank you for your time and assistance.

Kind Regards,

Gary

Answer 1

VPN Server: Assuming eth0 (IP 1.2.3.4) is the physical interface that is directly attached to or at least has the route to the target web-server's IP or network, you can monitor any traffic destined to the web-server IP 172.67.168.48:443, to be forced through the VPN tunnel and then NATted out to eth0's IP address (1.2.3.4 in this example). In this case, br0 interface (IP 10.10.10.1) is the virtual interface that the VPN server is using to tunnel the traffic. While the VPN is up and running, it already knows how to route packets to destination IP 172.67.168.48

If not, then you have to add a static route:

$ ip route show
172.67.168.48/32 via 10.10.10.1 dev br0 metric 101

Once the route statement is satisfied, then you can force traffic destined to IP 172.67.168.48:443 to be routed through the tunnel and exit on the other side as 1.2.3.4 en-route 172.67.168.48

$ sudo iptables -t nat -A POSTROUTING -o eth0 -p tcp -m tcp -d 172.67.168.48 --dport 443 -j SNAT --to-source 1.2.3.4
$ sudo iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

If a client sends a packet to 172.67.168.48:80 for example, the source IP will not change, and the packet may be discarded if not allowed by subsequent chains.

Answer 2

All:

It turns out my original iptables -t nat rule was missing the --dport 443 definition and the reason why it was interacting with Other HTTP requests.

# Create the RPDB rules
ip rule add from 0/0 fwmark "0x1000/0x1000" table ovpnc1 prio 9993        # VPN 1 fwmark

iptables -t mangle -A PREROUTING -i br0 -p tcp --dport 443 -d 172.67.168.48 -j MARK --set-mark 0x2000/0x2000
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 443 -j DNAT --to-destination 172.67.168.48:443 -m mark --mark 0x2000/0x2000

Once the --dport 443 definition was added to the iptables -t nat rule the issue was resolved.

Hope this helps someone else in the future.

Respectfully,

Gary