[Klug-general] Multiple routes out [SOLVED]

[Alan Buchel]

>> We have a Server inside a private network which routes out through a  
>> WLAN switch as it's main uplink to the internet. It syncs with other  
>> servers over this network. For reasons beyond my control, the server is  
>> only allowed 1 IP address. Now we want to expose some of the services on  
>> this server such as www (80) to the outside world via a broadband line,  
>> and such a facility is unavailable via the WLAN.
>>     
> OK, so the problem that you have here is that the Smoothwall will do a
> port forward ie. translate the destination address and port of the
> incoming packet but the source address will remain the same.  Consider
> this scenario:
>
> Client 1.2.3.4 connections to the smoothie on the red interface (let's
> say that interface has an IP address of 90.90.90.90).  Smoothwall
> translations the destination address from 90.90.90.90 to the internal
> address of the server (let's say 192.168.0.50).  So, the server receives
> a packet that has a source of 1.2.3.4 and a destination of 192.168.0.50.
> It then responds with the customary syn/ack and since the source of
> 90.90.90.90 is outside of it's local subnet, it sends the packet to its
> default gateway (in this case, the WLAN).  The client 1.2.3.4 then
> recieves the syn/ack from 192.168.0.50 which it never contacted in the
> first place.
>
> The way to resolve this is to get the Smoothie to translate the source
> address of the incoming packet to the IP of the green interface.  This
> can be done with iptables either by a source NAT or using IP
> masquarading.  The latter is probably simpler and can probably be turned
> on in smoothwall's config tool.  Failing that iptables -t nat -A
> PREROUTING -i $red_int -o $green_int -j MASQUARADE is roughtly what you
> are looking for, though you may want to check that manual as that's off
> the top of my head.
>
> Mike.
>   
Correct it is because of the default route back to the originator that
the transaction does not take place. The trick is to present the packets
to the Server *as if* they are coming from Smoothie, this way the
response is passed directly back to Smoothwall which in turn passes back
to originator, and not via Server's default route to the originator
which would be ignored for the reason Mike stated above.

Thanks muchly to the helpful peeps on the Smoothwall Forums, I found that:

iptables -t nat -I POSTROUTING -o eth1 -d 10.20.225.30 -j SNAT
--to-source 10.20.225.31
Where:
10.20.225.31(eth1)=SMOOTHWALL_GREEN
10.20.225.30=Server inside GREEN network

..stuck it in rc.firewall.up and Job Done :)

Thanks Mike for translating the issue so well.