LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 02-20-2017, 09:12 PM   #1
sloppytypist
LQ Newbie
 
Registered: Dec 2016
Posts: 13

Rep: Reputation: Disabled
DNAT not working on Ubuntu 16


Hi,

I've a strange problem. I've done this many times before, but not today. I'm trying to DNAT 1:1 to a device. In this case the device is at 172.21.0.25. I can ping the device no problem from the Ubuntu 16.04(4.8 kernel)but when I setup the following DNAT it responds to my test ping with ICMP host unreachable.

I confirmed

So it should the server on 172.30.5.206 then > 172.21.0.25.

This is my iptables nat rules:

root@ip-172-30-5-161:/home/ubuntu# iptables -t nat -S -v
-P PREROUTING ACCEPT -c 0 0
-P INPUT ACCEPT -c 0 0
-P OUTPUT ACCEPT -c 1 60
-P POSTROUTING ACCEPT -c 1 60
-A PREROUTING -d 172.30.5.206/32 -c 1 60 -j DNAT --to-destination 172.21.0.25
root@ip-172-30-5-161:/home/ubuntu#

All other policies are set to ACCEPT:

root@ip-172-30-5-161:/home/ubuntu# iptables -S -v
-P INPUT ACCEPT -c 8649 550346
-P FORWARD ACCEPT -c 20 1200
-P OUTPUT ACCEPT -c 8367 580846
root@ip-172-30-5-161:/home/ubuntu#

Here is my routing table:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.30.5.1 0.0.0.0 UG 0 0 0 eth0
172.21.0.0 * 255.255.254.0 U 0 0 0 vti1
172.30.5.0 * 255.255.255.0 U 0 0 0 eth0

Here are my IPs

root@ip-172-30-5-161:/home/ubuntu# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
link/ether 06:f2:02:c4:12:88 brd ff:ff:ff:ff:ff:ff
inet 172.30.5.161/24 brd 172.30.5.255 scope global eth0
valid_lft forever preferred_lft forever
inet 172.30.5.206/24 brd 172.30.5.255 scope global secondary eth0:10
valid_lft forever preferred_lft forever
inet6 fe80::4f2:2ff:fec4:1288/64 scope link
valid_lft forever preferred_lft forever
3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 56:af:d1:d4:4e:4c brd ff:ff:ff:ff:ff:ff
4: OVSBR: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 76:a0:55:27:b8:47 brd ff:ff:ff:ff:ff:ff
5: ip_vti0@NONE: <NOARP> mtu 1332 qdisc noop state DOWN group default qlen 1
link/ipip 0.0.0.0 brd 0.0.0.0
6: vti1@NONE: <NOARP,UP,LOWER_UP> mtu 1332 qdisc noqueue state UNKNOWN group default qlen 1
link/ipip 172.30.5.161 brd 0.0.0.0
inet 172.21.0.1/23 scope global vti1
valid_lft forever preferred_lft forever

Here is proof I'm ready to route:

root@ip-172-30-5-161:/home/ubuntu# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Here is proof that the host is reachable:

root@ip-172-30-5-161:/home/ubuntu# ping 172.21.0.25
PING 172.21.0.25 (172.21.0.25) 56(84) bytes of data.
64 bytes from 172.21.0.25: icmp_seq=1 ttl=64 time=35.8 ms


Related note, when I change the DNAT to be the IP(172.21.0.1) on vti1 that is directly connected to the 172.21.0.0/23 subnet, it works, but tcpdump does not show traffic on vti1. What am I missing? Thanks.

CB

Last edited by sloppytypist; 02-21-2017 at 08:38 AM.
 
Old 03-03-2017, 11:58 AM   #2
lazydog
Senior Member
 
Registered: Dec 2003
Location: The Key Stone State
Distribution: CentOS Sabayon and now Gentoo
Posts: 1,249
Blog Entries: 3

Rep: Reputation: 194Reputation: 194
Run the following commands and post their output in between [ C O D E ] tags.
CODE Tags are found on the Advance page under the # symbol. Just highlight want you want in code tags and click the symbol.

Code:
iptables-save > /tmp/iptables
route -n
ifconfig
 
Old 03-03-2017, 01:20 PM   #3
sloppytypist
LQ Newbie
 
Registered: Dec 2016
Posts: 13

Original Poster
Rep: Reputation: Disabled
Command returns below. I did discover something else. When I SNAT the address to a local address on the device, it works. That said, changing the source address is not a good solution here. To mention again, the packets do not get to the other device.

root@ip-172-30-5-161:/home/ubuntu# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.30.5.1 0.0.0.0 UG 0 0 0 eth0
172.21.0.0 0.0.0.0 255.255.254.0 U 0 0 0 vti1
172.30.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
root@ip-172-30-5-161:/home/ubuntu#

root@ip-172-30-5-161:/home/ubuntu# ifconfig
eth0 Link encap:Ethernet HWaddr 06:f2:02:c4:12:88
inet addr:172.30.5.161 Bcast:172.30.5.255 Mask:255.255.255.0
inet6 addr: fe80::4f2:2ff:fec4:1288/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1
RX packets:6016702 errors:0 dropped:0 overruns:0 frame:0
TX packets:6078942 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1047337572 (1.0 GB) TX bytes:1344270332 (1.3 GB)

eth0:10 Link encap:Ethernet HWaddr 06:f2:02:c4:12:88
inet addr:172.30.5.206 Bcast:172.30.5.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1100446 errors:0 dropped:0 overruns:0 frame:0
TX packets:1100446 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:124877644 (124.8 MB) TX bytes:124877644 (124.8 MB)

vti1 Link encap:IPIP Tunnel HWaddr
inet addr:172.21.0.1 Mask:255.255.254.0
UP RUNNING NOARP MTU:1332 Metric:1
RX packets:2001303 errors:17 dropped:17 overruns:0 frame:0
TX packets:2038319 errors:1159895 dropped:0 overruns:0 carrier:1159895
collisions:0 txqueuelen:1
RX bytes:608155483 (608.1 MB) TX bytes:992546478 (992.5 MB)

root@ip-172-30-5-161:/home/ubuntu#



root@ip-172-30-5-161:/home/ubuntu# cat /tmp/iptables
# Generated by iptables-save v1.6.0 on Fri Mar 3 19:12:49 2017
*raw
:PREROUTING ACCEPT [1150286:80419690]
:OUTPUT ACCEPT [1068178:62844221]
-A PREROUTING -s 172.21.0.25/32 -j TRACE
-A PREROUTING -s 216.189.151.142/32 -i eth0:10 -j TRACE
-A PREROUTING -d 172.30.5.206/32 -j TRACE
-A OUTPUT -d 172.21.0.25/32 -j TRACE
-A OUTPUT -d 216.189.151.142/32 -o eth0:10 -j TRACE
-A OUTPUT -s 172.30.5.206/32 -j TRACE
COMMIT
# Completed on Fri Mar 3 19:12:49 2017
# Generated by iptables-save v1.6.0 on Fri Mar 3 19:12:49 2017
*nat
:PREROUTING ACCEPT [209147:12551102]
:INPUT ACCEPT [209147:12551102]
:OUTPUT ACCEPT [36058:2207363]
:POSTROUTING ACCEPT [36074:2208364]
-A PREROUTING -d 172.30.5.206/32 -j DNAT --to-destination 172.21.0.25
COMMIT
# Completed on Fri Mar 3 19:12:49 2017
# Generated by iptables-save v1.6.0 on Fri Mar 3 19:12:49 2017
*filter
:INPUT ACCEPT [1227753:86670071]
:FORWARD ACCEPT [71710:6148199]
:OUTPUT ACCEPT [1165319:68882495]
-A OUTPUT -p gre -j NFQUEUE --queue-num 10 --queue-bypass
COMMIT
# Completed on Fri Mar 3 19:12:49 2017
 
Old 03-03-2017, 10:11 PM   #4
lazydog
Senior Member
 
Registered: Dec 2003
Location: The Key Stone State
Distribution: CentOS Sabayon and now Gentoo
Posts: 1,249
Blog Entries: 3

Rep: Reputation: 194Reputation: 194
What are you using or following to create your firewall rules?
Do you really need the raw tables?
Where is the -j TRACE going?
 
Old 03-03-2017, 10:27 PM   #5
sloppytypist
LQ Newbie
 
Registered: Dec 2016
Posts: 13

Original Poster
Rep: Reputation: Disabled
Hi Robert,

I added the traces after it wasn't working. I've used a few different guides and docs. If I remove those traces, the problem is the same.

CB

Last edited by sloppytypist; 03-04-2017 at 12:24 PM.
 
Old 03-07-2017, 06:53 AM   #6
lazydog
Senior Member
 
Registered: Dec 2003
Location: The Key Stone State
Distribution: CentOS Sabayon and now Gentoo
Posts: 1,249
Blog Entries: 3

Rep: Reputation: 194Reputation: 194
Sorry for the late reply Life happens.
I believe I know what is happening.

Quote:
So it should the server on 172.30.5.206 then > 172.21.0.25.
You are DNATing traffic from 172.30.5.206 to 172.21.0.25 but you are not SNATing the return traffic.

The client sends a packet to 172.30.5.206 and the host responds with 172.21.0.25. Since the client doesn't know these are the same host it discards the return packet as it never attempted to contact that ip address and is expecting a response from 172.30.5.206 not 172.21.0.25.

There are a couple of ways to get around this.
  1. Use the assigned IP Address of the host and not DNAT anything.
  2. DNAT and SNAT all traffic for 172.21.0.25
  3. Use the MARK function to mark the packets that need to be SNATed.
The above are listed in order from easiest to hardest in terms of what you need to know about networking and IPTABLES.
 
Old 03-17-2017, 10:04 PM   #7
sloppytypist
LQ Newbie
 
Registered: Dec 2016
Posts: 13

Original Poster
Rep: Reputation: Disabled
Hi Robert,

It was a RPF check issue. I didn't realize Linux did this be default. Thanks for your time!

CB
 
Old 03-17-2017, 11:03 PM   #8
lazydog
Senior Member
 
Registered: Dec 2003
Location: The Key Stone State
Distribution: CentOS Sabayon and now Gentoo
Posts: 1,249
Blog Entries: 3

Rep: Reputation: 194Reputation: 194
Interesting, how did you come to this or how did you figure this out? I'd like to know for future reference.
Thnx.
 
Old 03-23-2017, 03:28 PM   #9
sloppytypist
LQ Newbie
 
Registered: Dec 2016
Posts: 13

Original Poster
Rep: Reputation: Disabled
A little help from my friends. Here's the correspondence with Rob White in the netfilter listserv:

> Stupid questions:
>
> (0) Have you tried the ping from the firewall or from a separate host, or from both.
>
> Packets coming in down from the top (e.g. originating on the local host) are sometimes weird.
>
> I would. at the least, turn on logging of reverse path filtering.
>
> http://tldp.org/HOWTO/Adv-Routing-HO...ernel.rpf.html
>
> You may find that one of these options -- e.g. the one you aren't currently using in the test -- works when the other does not. If so you know where you need to concentrate.
>
>
> (1) What does /proc/sys/net/ipv4/conf/vti0/forwarding say? how about .../lo0/...?
>
> If /proc/sys/net/ipv4/conf/default/forwarding=1 was not true when the interface was configured, or if some option in the configuration is turning it off... well that could prevent output.
>
> (2) Have you configured vti_routing=yes (or equivelent) in the necessary config file for libreswan (or whatever you are using)?
>
> Routing incoming packets out a VPN is usually _not_ the default.
>
> (3) Does "iptables -t nat --list -v" show the counters on the DNAT rule increasing when you initiate the ping?
>
> (4) have you tried adding a "--match conntrack --ctstate DNAT -j LOG"
>
>
> (5) What's with ext0:10?
>
> Virtual ethernet adapters are so last century. 8-)
>
> More seriously, is this a residue from something like an old configuration scripting scheme? It's better for everything to just add the extra address to the base interface. A simple "ip address add dev eth0 172.30.5.206/24" would be much better.
>
> For example, to talk to my cable modem's maintenance interface...
>
> # ip address add dev ext0 192.168.100.5/24
> # ip address show ext0
> 7: ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group 1 qlen 1000
> link/ether 00:1b:21:98:04:af brd ff:ff:ff:ff:ff:ff
> inet 73.109.XXX.XXX/21 brd 255.255.255.255 scope global ext0
> valid_lft forever preferred_lft forever
> inet 192.168.100.5/24 scope global ext0
> valid_lft forever preferred_lft forever
> inet6 fe80::21b:21ff:fe98:4af/64 scope link
> valid_lft forever preferred_lft forever
>
>
> (6) Does /proc/sys/net/ipv4/conf/*/route_localhost settings alter your ping test?
>
> (7) Have you tried any connections types other than ping?
>
>
>
> ---
>
> That's pretty much the list of starting places that came to mind. Hope this helped.
>
> -Rob.

__________________________________________________________________________________________________


Hi Robert,

I have to tell you I am so happy to know that Linux does RP filter by default. It gave me flashbacks to CCIE multicast routing troubleshooting. I changed it:


root@ip-172-30-5-161:/home/ubuntu# for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do cat $i; done
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
root@ip-172-30-5-161:/home/ubuntu#

(0) Have you tried the ping from the firewall or from a separate host, or from both.

Yes. I have a GRETAP sessions each way actually working(that wasn't easy). Though unrelated, iptables/NF would be well served to add clear-DF-bit function. I'm pulling packets out of kernel space with nf-queue to clear df-bit, recalc checksum, and send on. It's gross. #MTUhell


(1) What does /proc/sys/net/ipv4/conf/vti0/forwarding say? how about .../lo0/...?

root@ip-172-30-5-161:/home/ubuntu# cat /proc/sys/net/ipv4/conf/vti1/forwarding
1

root@ip-172-30-5-161:/home/ubuntu# cat /proc/sys/net/ipv4/conf/lo/forwarding
1

(2) Have you configured vti_routing=yes (or equivelent) in the necessary config file for libreswan (or whatever you are using)?

That was a good idea! I checked with the strongswan and found this recommendation. (https://wiki.strongswan.org/projects.../RouteBasedVPN)

sysctl -w net.ipv4.conf.<name>.disable_policy=1

root@ip-172-30-5-161:/home/ubuntu# cat /proc/sys/net/ipv4/conf/vti1/disable_policy
1

Sadly it didnt fix the problem.

(3) Does "iptables -t nat --list -v" show the counters on the DNAT rule increasing when you initiate the ping?

It increases by 1, then drops. Here are two ping test(4 pings each) about a 2 mins apart.

root@ip-172-30-5-161:/home/ubuntu# iptables -t nat -S -v
-P PREROUTING ACCEPT -c 1720 103200
-P INPUT ACCEPT -c 1720 103200
-P OUTPUT ACCEPT -c 65 4353
-P POSTROUTING ACCEPT -c 68 4533
-A PREROUTING -d 172.30.5.206/32 -c 3 180 -j DNAT --to-destination 172.21.0.25
-A PREROUTING -d 172.30.5.206/32 -c 0 0 -j DNAT --to-destination 172.21.0.1


(4) have you tried adding a "--match conntrack --ctstate DNAT -j LOG"

Yes.


(5) What's with ext0:10?

Virtual ethernet adapters are so last century. 8-)

Yeah, I'm an old guy.

(6) Does /proc/sys/net/ipv4/conf/*/route_localhost settings alter your ping test?

No

(7) Have you tried any connections types other than ping?

Yes. SSH also fails.


All that said, there is good news! After disallowing RP check, disabling policies and changing the traffic selectors in strongswan, it's working great. Thanks a bunch for your time! I really appreciate it.

Chris
 
  


Reply

Tags
dnat, iptables, nat, netfilter



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
iptables DNAT not working on new site. SBS1 Linux - Networking 15 04-01-2013 03:08 PM
DNAT rule not working for private IP. atta.memon@gmail.com Linux - Newbie 1 05-20-2009 07:56 PM
My DNAT/port fowardin isn't working Niceman2005 Linux - Security 31 09-16-2006 09:34 PM
DNAT not working stevesl Linux - Networking 13 05-16-2005 11:22 PM
Iptables/DNAT not working! I'm going insane! renmo Linux - Networking 5 05-18-2003 07:51 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 04:39 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration