2

We have a network mostly set up with a redundant pair of Linux Iptables firewalls/routers, but we're missing a crucial piece of the puzzle. Any local traffic destined to the secondary router succeeds in the same subnet, but fails to the "main" router ip. Here's an example:

Network Diagram

Router1 and Router2 both have interfaces on 10.0.0.0/24 (Subnet0) and 10.0.1.0/24, (Subnet1) with a VIP 10.0.1.1 shared via ucarp.

Webserver1 has IP 10.0.1.11, and its default gateway is 10.0.1.1

Pings are successful from Webserver1 to Router1 on the Subnet0 and Subnet1 interfaces

Pings are successful, as expected, from Webserver1 to Router2 on the Subnet1 interface. (no routing involved)

However, pings fail from Webserver1 to Router2 on the Subnet0 interface. Router1 receives the echo request on the Subnet1 interface and forwards it out the Subnet0 interface, as expected, but when the echo requests arrive at Router2 on the correct (Subnet0) interface, Router2 does not send a reply.

Router2 logs a martian packet each time this occurs. Jul 31 21:39:33 Router2 kernel: [2772508.610259] martian source 10.0.0.3 from 10.0.1.11, on dev bond0.1000

We think the martian log line is caused by the packet arriving on a different interface from a network that the router already has a different interface on, which the system considers an invalid source interface. What is the solution to this problem? Should we be doing something like SNAT when Router1 sends to Router2?

righdforsa
  • 283
  • 4
  • 13
  • How do you know that Router2 is not sending a reply? If you're using something like `tcpdump`, use `-i any` to see traffic on all interfaces and make sure it's not sending the reply out it's Subnet1 interface (which is what it should be doing). – larsks Jul 26 '13 at 01:40
  • Yeah, I have been using "tcpdump -i any" to watch the traffic, and all I see is the ICMP echo request. – righdforsa Jul 26 '13 at 04:39

2 Answers2

1

This is very likely a suggestion that comes to late. And not even a full blown answer.

I don't know what you are running on your routers, but you might be able to use the reverse path filters, i.e. you could partially turn them off. I think most Linux distributions allow you to set the rp_filter to levels 0,1,2. By default it will be 1, which causes this packet to be dropped. 0 will just let all 'impossible' traffic through, but 2 will allow packets on both interfaces, if either interface would let them through, which could work in your case.

I do not know the extend of the security risks this will bring with it, but it seems to me that if one of the interfaces would allow, you should not really have a problem.

Oxidator
  • 126
  • 4
  • Wow, thanks Oxidator, we're on Linux, so that is a great suggestion. Sorry I missed this at the time, but we'll totally look into that! – righdforsa Oct 30 '14 at 18:43
0

I'm going to take a stab at this answer, not having access to your iptables config and routing config. I have a very similar setup, though, and have had this sort of issue.

I'm assuming you're SNATing traffic from 10.0.1.0/24 to your public IP (or using MASQUERADE). Try putting a line before all other SNAT/MASQ declarations similar to:

iptables -A POSTROUTING -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT

That will bypass your later SNAT rules for traffic from/to your local networks.

Also, make sure you have a forwarding rule set up appropriately. For testing purposes, allow all traffic between 10.0.0.0/8 addresses (assuming you don't already have an appropriately permissive rule). E.g.:

iptables -A FORWARD -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT

If I'm completely off base, please post the output of the following for both routers:

iptables -nL
iptables -nL -t nat
ip rule show
ip route show
ip route show table XXXX  (For each table listed as a lookup in rules)
s.co.tt
  • 702
  • 7
  • 15
  • Thanks, but that didn't work. The packets are already arriving on Router2's Subnet0 interface, so the SNAT on Router1 doesn't seem to be involved. (Good guess, though) Found the log line I was searching for; Router2 seems to be discarding them because they are martian packets. Updating the OP. – righdforsa Jul 31 '13 at 21:45