iptables NAT prerouting rule does not forward the traffic?
Hello,
on one server, the iptables rule like: iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 48280 -j DNAT --to 10.8.0.2:48280 worked to forward server's incoming traffic at mentioned port into the VPN tunnel where the VPN client network interface has IP 10.8.0.2. Port appeared as open. Now when i tried the same rule on different server, the port appears closed, even i tried to disable client's firewall. The ifconfig shows the server has only lo, eth0 and tun0 interfaces so eth0 should be correct. Please what is the commands you would do to discover where the incoming traffic is stuck? some details about the server: Redhat based CentOS 7, kernel 3.10, iptables v1.4.21 lsmod|grep nat Quote:
iptables-save|egrep -i "reject|drop|deny" Quote:
iptables-save|egrep -i nat Quote:
Regarding client, it is Windows 10 |
Quote:
https://www.linuxquestions.org/quest...ip-4175495510/ https://www.linuxquestions.org/quest...id-4175667512/ https://www.linuxquestions.org/quest...es-4175506598/ https://www.linuxquestions.org/quest...ot-4175503912/ ...and pay particular attention to the last post in this thread: https://www.linuxquestions.org/quest...ml#post5742851 Again; we know nothing about your internal network, what IP addresses are in use on this server (past the one you posted), nor how you have determined the 'port appears closed'. Are you not able to look through the many, MANY threads you've opened in the past about iptables/firewalls/networking, and apply ANYTHING you've been told in the past??? Have you checked to see if IP forwarding is turned on???? And since you configured one server, why can't you use the EXACT SAME RULES (with small modifications, since the systems are obviously not the same), on the new system? You've been told several times in the past about how to backup and restore rule-sets, so that should be trivial for you to do. ::EDIT:: Some other resources you might want to reference. MANY references to prerouting and NAT'ing: https://www.lowendtalk.com/discussio...ted-in-any-lan https://www.lowendtalk.com/discussio...work-admin-vps http://www.vpnforums.com/index.php?a...=topics;u=3136 https://forums.cpanel.net/threads/ho...wntime.605855/ |
Quote:
Quote:
Code:
tcpdump -v -i eth0 port 48280 I would also use tcpdump or wireshark on the other side of the tunnel. Wireshark has a Windows edition, too, and tcpdump can be used on Windows via Cygwin if there is no native equivalent. Other suggestions: Check your netfilter rules again. Is there a rule before the DNAT that might interfere? Also, add a logging rule to the netfilter ruleset (-j LOG). |
Quote:
https://www.linuxquestions.org/quest...ow-4175667621/ |
Quote:
|
Quote:
Quote:
197 packets captured 1267 packets received by filter 915 packets dropped by kernel sample: Quote:
/etc/sysctl.conf shows the forwarding is enabled. (net.ipv4.ip_forward = 1) Firewall details i have shown in my first post. And as mentioned, on the client i tried to disable firewall during the capture, so i expect the problem to be on the server. Quote:
Quote:
Quote:
Quote:
Then this one started logging something: iptables -A INPUT -j LOG tail -f /var/log/messages Yet, it shows no traffic that match the port of my interest: tail -f /var/log/messages|grep 48280 Despite the "tcpdump -v -i eth0 port 48280" has quite intensive traffic output. What would you suggest to try @berndbausch |
Quote:
|
Quote:
Quote:
Quote:
COMPARE THE TWO...there has to be a difference somewhere. When you find it, MAKE IT MATCH. You also (AGAIN) don't tell us what environment you're in, tell us anything about your network topology, where these things run through, etc. Did you bother to check the DMZ? Hardware firewall??? You have to be running through those things in order to touch a public IP address. You were asked all of this in post #2, yet (as usual), don't supply any relevant information. You've been working with iptables/ufw for SEVEN YEARS; you have been handed exact commands for NAT'ing and forwarding, but each time you need to change something, you don't seem to be able to apply anything you've been told or learned, and instead ask for a handout. |
To find out where traffic disappears, you trace the interfaces through which traffic flows. Once you know where it disappears, you look at your netfilter rules once more.
I don't know which interface you traced when receiving this packet: Code:
14:23:12.123456 IP (tos 0x0, ttl 114, id 28290, offset 0, flags [DF], proto TCP (6), length 52) Quote:
|
Quote:
The client's Wireshark shows some TCP connections at that port 48280, but when the source is some unknown remote IP, then the connection is red with flags RST, ACK. I found this tool can tell the port status: https://check-host.net/check-tcp https://check-host.net/check-udp and it seems to properly report udp port status as "open or filtered" and the non-forwarded UDP port status as closed. But it always report closed in case of a TCP. So the problem looks to be in a TCP (forwarding on the server?), but i am really unsure why UDP yes and TCP no. # iptables -L FORWARD Quote:
# iptables -L -t nat|grep DNAT Quote:
|
Quote:
Quote:
Have you done this? Have you checked this??? Quote:
You are not providing details about your network topology, just posting rulesets and asking us to diagnose them for you. After so many years, are you not able to do any sort of diagnostics on your own?? Are you unable to use the tools that people have told you about dozens of times??? Why can you not apply anything you've been told? |
I have to admit that I know nothing about your architecture, about Windows, a client, virtual machines and so on. I know you have a Linux server with a NIC eth0 and a tunnel endpoint tun0. Traffic to port 48280 is supposed to enter via eth0 and get forwarded to the tunnel. Is that correct?
If so, first check if traffic arrives at eth0 at all. tcpdump can reveal that. Next, check if those packets flow through tun0. If so, the problem is not your netfilter rules. If not, I would first check what the routing tables do with destination 10.8.0.2. Is it routed to tun0 at all? If not, fix this. In case traffic does arrive at eth0, the routing rules are correct and traffic does NOT go through tun0, you rework your netfilter rules. |
It seems solved now. The connections started going through (and recorded on server under tun0 interface - tcpdump -i tun0 tcp port 48280) when i removed the forwarding rule highlighted below:
Quote:
Below are other details even the above mentioned action solved the issue of this forum topic, i am leaving it here if you are insterested to know: Quote:
Quote:
tcpdump tcp port 48280 tcpdump -i eth0 tcp port 48280 Sample: Quote:
Quote:
I think that here comes your suggestion: Quote:
Quote:
Quote:
Quote:
# iptables -L FORWARD Quote:
Quote:
when i exported iptables (iptables-save > /etc/sysconfig/iptables_18.4.2020) created copy (cp -p /etc/sysconfig/iptables_18.4.2020 /etc/sysconfig/iptables_18.4.2020_mod) edited the copy (vi /etc/sysconfig/iptables_18.4.2020_mod) append: -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source myserveriphere after line: -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source myserveriphere save and import into firewall (iptables-restore < /etc/sysconfig/iptables_18.4.2020_mod) i then moved FORWARD rule: FORWARD -s 10.8.0.0/24 -j ACCEPT to the top |
You did all the checks that I recommended. You confirmed that 48280 traffic arrives at eth0 and does not flow through tun0 (tcpdump -i tun0 confirms that). You checked that traffic to 10.8.0.0 is indeed routed to tun0. All this is fine.
So the only reason I can see is a problem with your netfilter rules. They are rather complex - I guess you have a firewall that creates all these rules. The problem is that you interfere with the firewall by adding a DNAT rule, and that it's hard to get a grip on that interference. You seem to have the problem even when the firewall is off. But when it is off, the rules are simpler, I guess, which would make it easier to find out how packets are passed through netfilter. As far as I know, the only ways to deal with it are, again, manually checking the rules, perhaps performing a netfilter simulation on paper. Or using LOG rules that you place at useful positions in the rule set. I am not aware of a netfilter analyzer (but by all means, don't believe me). If you have found a solution, great. |
All times are GMT -5. The time now is 11:21 AM. |