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


  Search this Thread
Old 11-14-2016, 07:15 AM   #16
LQ Newbie
Registered: Nov 2016
Posts: 11

Original Poster
Rep: Reputation: Disabled

I'm going totally bonkers over this. I just can't get why the fwmark is ignored by the routing.

If I make a connection over ppp0, the reply is lost (as described) since it goes back out the wrong interface. If I then check the conntrack entry to find the client address, and then just add a explicit rule to send packets destined to that address, then it works as it should.

Example conntrack entry:
udp      17 25 src= dst= sport=34624 dport=41000 src= dst= sport=41000 dport=34624 mark=1 use=1
If I then add a rule like this:

500:    to lookup ppproute works. This is of course expected under the assumption that routing happens after the final reversal of the DNAT.

If only the rule for the fwmark had worked, my problem would have been solved. As the conntrack entry shows, the connection is indeed marked as requested, so why doesn't routing see the mark? Is it somehow lost before routing happens, even though it shows up in the conntrack entry?
Old 11-14-2016, 08:34 PM   #17
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
Where in your rules SPECIFICALLY are you doing the DNAT and SNAT?
Would it be possible to share you rules?
Old 11-14-2016, 08:43 PM   #18
LQ Newbie
Registered: Nov 2016
Posts: 11

Original Poster
Rep: Reputation: Disabled
I'm not doing explicit SNAT, instead I'm masquerading (which in this case should do exactly the same thing), as shown in the first post. DNAT is also in that first post, the rules are all there. Only I have modified the DNAT rule to add ct marking, also outlined in the first post:

iifname "ppp0" udp dport 41000-41002 ct mark set 0x1 dnat
Any incoming packets on ppp0 to UDP ports 41000-41002 are DNATed to, and also conntrack marked with 0x1.
Old 06-29-2017, 05:52 AM   #19
LQ Newbie
Registered: Nov 2016
Posts: 11

Original Poster
Rep: Reputation: Disabled
My problems here hasn't really been solved, I just worked around them in a way I'm not happy with, so I'm returning to it. I now know why the marking stuff I tried did not work, I had failed to understand that the routing itself can't see the connection mark, only the packet mark. And I never tried writing the connection mark to the packet mark.

However, I am still in the dark as to why the return packets are not routed correctly, so I'd like to revisit this. The one crucial point here is the routing of the return packets. After browsing literally hundreds of web pages, I still haven't found an answer to exactly when SNAT and DNAT is "reversed" (or un-SNATed and un-DNATed if you like).

When the first packet enters the ppp0 interface, the DNAT rule triggers, and rewrites the destination address. Then the routing decision is made, and the packet should leave on the eth1 interface. As it hits the postrouting, the masquerading rewrites the source address to the eth1 address, and the packet leaves eth1. So far so good, and the connection entry looks like this:

udp      17 28 src= dst= sport=12345 dport=51000 [UNREPLIED] src= dst= sport=51000 dport=12345 mark=0 use=1
Now the server replies as expected and the conntrack entry changes to:

udp      17 27 src= dst= sport=12345 dport=51000 src= dst= sport=51000 dport=12345 mark=0 use=1
The [UNREPLIED] state is removed, since conntrack was able to match the reply.

The reply packet (as it enters eth1) has a source address of, and a destination address of (the router's eth1 address). At this point, the packet needs to have both the source and destination addresses changed, but in which order does this happen, and at which point is the routing table consulted?

The routing rules are:

0:      from all lookup local
2000:   from lookup ppproute
32766:  from all lookup main
32767:  from all lookup default
And if I ask ip route how it would route a packet for from

ip route get to from from dev ppp0
    cache tells me it would in fact use the ppp0 interface (which is what I want).

For the packet flow outlined above, this does not happen, the reply instead leaves out eth0. What this means is obviously that the routing decision is made before both the source and destination addresses are rewritten/reversed.

So, can someone tell me exactly when the packet addresses are changed within netfilter/nftables/conntrack for a packet flow that is forwarded through a router and where both DNAT and SNAT (masquerading) is used? And at which points the routing decisions happen?

One more minor point: The rule 2000 above does in fact work when I ping the ppp0 interface from the outside, and ensures that the ping reply goes back where it should. If I remove the rule, the ping reply goes out eth0 (the default route) and is lost. I'm mentioning this just to clarify that the routing rule itself seems to work as intended when the source address is


Thread Tools Search this Thread
Search this Thread:

Advanced Search

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
[SOLVED] Getting return traffic back onto the LAN after traversing tun0 interface Parbold Linux - Networking 1 10-17-2014 11:35 AM
unable to get default ip address for interface connected back to back chakka.lokesh Linux - Networking 5 08-25-2014 04:02 AM
Traffic Control with iproute2 Tux-Slack Slackware 5 03-21-2008 04:27 PM
Traffic Shaping not queuing to correct subclass SiegeX Linux - Networking 3 12-12-2007 08:35 PM
LXer: QoS And Traffic Shaping For VoIP Users Using iproute2 And Asterisk LXer Syndicated Linux News 0 05-21-2007 09:31 PM > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 01:22 AM.

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