Redirecting to another gateway on the LAN

  • Brian Ronald

    Brian Ronald - 2012-03-15

    I'm probably missing something obvious.  Here's a quick description of what I have:

    A LAN, with workstations. This LAN has one Ubuntu Linux server with two network cards which is there to serve as a firewall. Beyond it, the internet. Also on the LAN is another firewall, over which I have no control, which provides access to another network, over which I also have no control.

    Workstations on my LAN require access to the network beyond that other firewall, which provides access to resources based on their IP addresses. Workstations requiring access must use specific ranges of IP addresses.

    My firewall knows about that other one, and routes packets by destination to it. Other packets with a non-local destination are sent out to the internet. Workstations must use my firewall as the default route in order to use the internet.

    My firewall has a very closed set of rules. Default policy is not to allow traffic through, with exceptions granted to certain sites and protocols. The firewall uses NAT to the outside world, and has some incoming NAT rules to forward outside ports to boxes on the inside.

    My problem is that connection attempts to addresses on the other network are failing. I've tried all sorts of rules to let traffic entering my firewall's inside interface, but destined for that other network, to leave unmolested. Alas, it seems that only the first SYN makes it; the SYN/ACK coming back from the other firewall goes directly to the workstation that sent the SYN, and my firewall never sees it. So, when the workstation sends its ACK, my firewall blocks it on the last rule (block all, all, all). None of my rules seem to be able to match it - only the very last one catches it. If that rule is set to allow, then traffic is redirected properly and all connection succeed. I can't have the firewall open like that, though. I toyed with using NAT to rewrite all the packets, but the rules on that other firewall didn't like connections that appeared to come from mine.

    My work-around is to get *another* Linux box, with one network card, configured with IP forwarding enabled and a comprehensive routing table. It re-sends the first packets itself, sends ICMP Redirects to workstations, and the connections all work. I feel that I must be missing something, though - I shouldn't need another box just for that!  Does anybody have any idea what I might be missing?

  • Vadim Kurland

    Vadim Kurland - 2012-03-16

    there is no easy solution to this. The rule in your firewall is probably configured to be stateful (which is the default) but it can't allow ACK packets coming from the workstation because it never saw the SYN/ACK packet and so did not see complete three-way tcp handshake and did not create state entry for this session.

    You can make the rule stateless using checkbox in the rule options dialog, this will permit any packet regardless of where it is in the TCP protocol state. Another option is to use NAT to change source address of packets headed for the "other network" to be the one that belongs to your firewall. This will make the "other" firewall send replies back to it instead of to workstations directly, which means your firewall will see all packets and stateful rules will work.

  • Brian Ronald

    Brian Ronald - 2012-03-17

    Thanks. I had already tried the second suggestion, but the other firewall cares very much about source IP address. I'll try the stateless idea on Monday.

  • Brian Ronald

    Brian Ronald - 2012-03-18

    vkurland, you're lovely. I managed to get in today. I wasn't aware of the stateless checkbox, and it has solved my problem completely.

    The rule I have used is to allow all traffic from the LAN side of the firewall, on (negated) external interface, with the stateless checkbox. As far as I'm concerned, if it's from inside and not actually trying to come through the firewall, it's free to go wherever it likes.

    Thank you very much for your help.


Log in to post a comment.