{"id":1112,"date":"2012-01-03T15:35:41","date_gmt":"2012-01-03T23:35:41","guid":{"rendered":"http:\/\/www.redwireservices.com\/?p=1112"},"modified":"2014-07-25T16:59:45","modified_gmt":"2014-07-25T23:59:45","slug":"linux-route-reply-packets-back-through-the-same-interface","status":"publish","type":"post","link":"https:\/\/www.redwireservices.com\/linux-route-reply-packets-back-through-the-same-interface","title":{"rendered":"Linux: Route Reply Packets Back Through The Same Interface"},"content":{"rendered":"
Once again I’m thwarted by the design of the Linux network stack. You see, by default, when a packet comes into one interface in Linux, you can’t count on the reply coming back through the same interface. This is not always a problem, but often if that reply was through a firewall the firewall will reject the reply connection as it comes from a different interface\/MAC address.<\/span><\/div>\n

\n<\/span><\/div>\n
This happened to me again today, for about the third inconvenient time. This time it was too much hassle to move things around, so I found a good solution from Novell<\/a>.<\/span><\/div>\n

\n<\/span><\/div>\n
I don’t know if it will persist reboots, but it’s enough to get me through a few days (we are moving to new IP space anyway). Here is what I did, in my case (192.x.98.192 was the newly added, badly behaving interface):<\/span><\/div>\n

\n<\/span><\/div>\n

\n<\/span><\/div>\n
sudo vi rt_tables # add table vlan98 with an unused id (252)<\/span><\/pre>\n
sudo ip route add 192.x.98.0\/24 dev eth1 src 192.124.98.192 table vlan98<\/span><\/pre>\n
sudo ip route add default via 192.x.98.1 dev eth1 src 192.124.98.192 table vlan98<\/span><\/pre>\n
sudo ip rule add from 192.x.98.192 table vlan98<\/span><\/pre>\n
I hope that saves someone some time.<\/span><\/div>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Once again I’m thwarted by the design of the Linux network stack. You see, by default, when a packet comes into one interface in Linux, you can’t count on the reply coming back through the same interface. This is not … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[11],"tags":[],"_links":{"self":[{"href":"https:\/\/www.redwireservices.com\/wp-json\/wp\/v2\/posts\/1112"}],"collection":[{"href":"https:\/\/www.redwireservices.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.redwireservices.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.redwireservices.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.redwireservices.com\/wp-json\/wp\/v2\/comments?post=1112"}],"version-history":[{"count":4,"href":"https:\/\/www.redwireservices.com\/wp-json\/wp\/v2\/posts\/1112\/revisions"}],"predecessor-version":[{"id":1496,"href":"https:\/\/www.redwireservices.com\/wp-json\/wp\/v2\/posts\/1112\/revisions\/1496"}],"wp:attachment":[{"href":"https:\/\/www.redwireservices.com\/wp-json\/wp\/v2\/media?parent=1112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.redwireservices.com\/wp-json\/wp\/v2\/categories?post=1112"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.redwireservices.com\/wp-json\/wp\/v2\/tags?post=1112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}