LinuxQuestions.org - iptables DNAT not working on new site.

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - iptables DNAT not working on new site. (https://www.linuxquestions.org/questions/linux-networking-3/iptables-dnat-not-working-on-new-site-4175455753/)

iptables DNAT not working on new site.

Hi there,

I've recently put together a proxy server for a friend's business using Squid. On my own network everything was working fine, however after it was moved to the business, I've found that port forwarding is no longer working.

The only changes made to it for the new network are IP settings, hostname (well the domain part only), and the DNS servers.

At present, I haven't configured Squid for the new site so that's disabled and out of equation at present. I'm focused on iptables.

Other then port forwarding, everything else is working. This device, the gateway/proxy, and the LAN machines can ping both internal & external addresses. I'm able to connect to this device via SSH remotely as well as its VPN from an external source so I know the INPUT chain is working.

What I'm finding most interesting is that when running 'iptables -t nat -L -v' I can see that the packets and bytes columns in the PREROUTING chain are increasing as I attempt to connect to these ports, so it can see my attempts at connecting. I'm thinking that it's unable to send back but I'm not filtering any outgoing traffic.

Here's the output of a number of files & commands;
I've replaced part of the IP address with 'xx' for privacy but they're correct in actual files.

/etc/network/interfaces

Code:

# The loopback network interface

auto lo

iface lo inet loopback



# External.

allow-hotplug eth0

iface eth0 inet static

        address 118.xx.190.22

        netmask 255.255.255.252

        gateway 118.xx.190.21



# Internal.

allow-hotplug eth1

iface eth1 inet static

        address 10.42.224.254

        netmask 255.255.255.0

iptables -L -v

Code:

Chain INPUT (policy DROP 1973 packets, 156K bytes)

 pkts bytes target    prot opt in    out    source              destination

 1505  141K ACCEPT    all  --  any    any    anywhere            anywhere            state RELATED,ESTABLISHED

 2972  374K ACCEPT    all  --  !eth0  any    anywhere            anywhere            state NEW

    5  212 ACCEPT    tcp  --  any    any    anywhere            anywhere            tcp dpt:ssh

    0    0 ACCEPT    tcp  --  any    any    anywhere            anywhere            tcp dpt:1723

    0    0 ACCEPT    udp  --  any    any    anywhere            anywhere            udp dpt:1723

    0    0 ACCEPT    gre  --  any    any    anywhere            anywhere



Chain FORWARD (policy ACCEPT 1642 packets, 289K bytes)

 pkts bytes target    prot opt in    out    source              destination



Chain OUTPUT (policy ACCEPT 5004 packets, 417K bytes)

 pkts bytes target    prot opt in    out    source              destination

iptables -L -v -t nat

Code:

Chain PREROUTING (policy ACCEPT 589 packets, 49947 bytes)

 pkts bytes target    prot opt in    out    source              destination

    1    44 DNAT      tcp  --  eth0  any    anywhere            anywhere            tcp dpt:3389 to:10.42.224.4



Chain POSTROUTING (policy ACCEPT 1171 packets, 91474 bytes)

 pkts bytes target    prot opt in    out    source              destination

 1153 91085 SNAT      all  --  any    eth0    anywhere            anywhere            to:118.xx.190.22



Chain OUTPUT (policy ACCEPT 1836 packets, 145K bytes)

 pkts bytes target    prot opt in    out    source              destination

route -n

Code:

Kernel IP routing table

Destination    Gateway        Genmask        Flags Metric Ref    Use Iface

118.xx.190.20  0.0.0.0        255.255.255.252 U    0      0        0 eth0

10.42.224.0    0.0.0.0        255.255.255.0  U    0      0        0 eth1

0.0.0.0        118.xx.190.21  0.0.0.0        UG    0      0        0 eth0

ip addr

Code:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    inet6 ::1/128 scope host

      valid_lft forever preferred_lft forever

2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

    link/ether ac:f1:df:79:22:d9 brd ff:ff:ff:ff:ff:ff

    inet 10.42.224.254/24 brd 10.42.224.255 scope global eth1

    inet6 fe80::aef1:dfff:fe79:22d9/64 scope link

      valid_lft forever preferred_lft forever

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

    link/ether 00:21:9b:37:f8:48 brd ff:ff:ff:ff:ff:ff

    inet 118.xx.190.22/30 brd 118.xx.190.23 scope global eth0

    inet6 fe80::221:9bff:xxxx:f848/64 scope link

      valid_lft forever preferred_lft forever

I can confirm that forwarding is still enabled on all interfaces.

Would anyone have any idea on how to fix this? It may take me a while for me to respond to this post if anyone would like any further information as I'll be AFK for the next few hours but I'll respond as soon as I can.

Massive thanks to any replies.

EDIT: I should mention that I'm running a fully up to date Debian Squeeze/stable.

Also a key difference between the two networks is that their one is going directly to the router, rather then another network as before. They do have an external static IP as in the /etc/networks file. Although I may be mistaken, I don't think this should be a problem.

There is no rule in forward chain. Whatever you have DANTED in PREROUTING chain. It is MUST be allowed in FORWARD chain. I think that is the issue. So put an allow rule in FORWARD chain for DNATED rules.

Hi KinnowGrower,

Thanks to your reply. I do know that port forward was working on my network without any FORWARD rules. It's set to ACCEPT the packets as well so they're not being dropped.

However, I'll be giving it a try for completeness. I'll respond with the findings in a few hours.

Just tried it. It made no difference. Although I do can see that the rule is being reached as its packet and bytes count increase. Without the rule, the increase appears at the global counter for the FORWARD chain.

It appears to be passing through the FORWARD chain even without the rule fine.

Just done a bit more digging on this. Using tcpdump, I can see my SYN packets are going through the internal interface but nothing is come back from it even though I know that the ports are open. Will keep looking.

make sure the iptable_nat module is loaded. You can check it with command

Code:

lsmod | grep nat

If not, load the module with command

Code:

modprobe iptable_nat

Also make sure host 10.42.224.4 is listening on port 3389

Hi KinnowGrower,

Thanks for your response but I can confirm that the iptable_nat module is running and the local machine's port is open and listening.

To SBS1:

Can you post output of the command "iptable-save" here. It is more informative.

Thanks.

There could be a SNAT issue, try adding the below rule.

iptables -t nat -I POSTROUTING -p tcp --dport 3389 -d 10.42.224.4 -j ACCEPT

@SBS1
Was looking at your DNAT rule. It seems, it is not as it supposed to be. Can you please run the following command to make it correct.

Code:

iptables  -I PREROUTING -t nat -d 118.xx.190.22 -p tcp -m multiport --dports 3389 -m state --state NEW --syn -j DNAT --to-destination 10.42.224.4

I am assuming 3389 is using TCP. replace xx with digits

@nimnull22;

Code:

# Generated by iptables-save v1.4.8 on Sun Mar 31 13:23:45 2013

*nat

:PREROUTING ACCEPT [0:0]

:POSTROUTING ACCEPT [9:696]

:OUTPUT ACCEPT [18:1398]

-A PREROUTING -i eth0 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 10.42.224.4

-A POSTROUTING -o eth0 -j SNAT --to-source 118.xx.190.22

COMMIT

# Completed on Sun Mar 31 13:23:45 2013

# Generated by iptables-save v1.4.8 on Sun Mar 31 13:23:45 2013

*filter

:INPUT DROP [188973:14795463]

:FORWARD ACCEPT [195804:83311658]

:OUTPUT ACCEPT [421793:33428965]

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT ! -i eth0 -m state --state NEW -j ACCEPT

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT

-A INPUT -p udp -m udp --dport 1723 -j ACCEPT

-A INPUT -p gre -j ACCEPT

COMMIT

# Completed on Sun Mar 31 13:23:45 2013

@hamlindsza;
Thanks, but no difference.

@KinnowGrower;
Tried that, with and without the previous DNAT rule in place, but it didn't work either.
Yes, it TCP. It's the default Windows RDP port. That rule was working fine, along with the other DNATs, when it was on my internal network.

Can you show the command you are invoking to test/check? and error message too?

can you please change the rule

Code:

-A INPUT ! -i eth0 -m state --state NEW -j ACCEPT

As per my knowledge this rule allow NEW connections only if interface is NOT eth0. But in your case it should be allowed

@SBS1:

Ok, let me analyse your proxy server. It has two interfaces:

Eth0 = 118.xx.190.22 - to outside world
Eth1 = 10.42.224.254/24 - connected to the LAN.

:FORWARD ACCEPT [195804:83311658]

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [9:696]
:OUTPUT ACCEPT [18:1398]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 10.42.224.4
-A POSTROUTING -o eth0 -j SNAT --to-source 118.xx.190.22

Everything looks good. So packets which comes to 118.xx.190.22:3389 will go to 10.42.224.4:3389.
If you said - ..."Other then port forwarding, everything else is working. This device, the gateway/proxy, and the LAN machines can ping both internal & external addresses" and ANY hosts in 10.42.224.0/24 LAN (even 10.42.224.4 )can ping 208.67.222.222, then I would suggest to execute command "tcpdump -nnt -i XXX" on 10.42.224.4 host and let us see the result.
Also, if it is possible, tell what is interface configuration on 10.42.224.4 (GW and mask)

Thanks.