IPSec, IPTables, multiple subnets

Hello,

How do you tell IPTables to not masquerade several specific subnets,
or alternatively, masquerade *only* one specific subnet but not
everything else?

We have several remote sites with the following subnets:

site1 (main office): 10.175.0.0/24
site2 (remote): 10.175.1.0/24
site3 (remote): 10.175.2.0/24
site4 (remote): 10.175.3.0/24

We are wanting to run full two-way site-to-site VPNs between the
remote sites and the main office. We are able to get one tunnel
working properly, but the others, while the tunnels are indeed up, we
cannot ping across to them from the main office. The VPN is IPSec.

Here is the current masquerading rule (on the main office firewall/
gateway), which is allowing the one IPSec tunnel to work no problem:

iptables -t nat -A POSTROUTING -o eth0 -d ! 10.175.1.0/24 -j
MASQUERADE

which is saying to masquerade all traffic going through eth0 *except*
for traffic destined for the 10.175.1.0/24 network.

IPSec does not create it's own interface unfortunately, but rather
"shares" eth0.

I have tried this rule:

iptables -t nat -A POSTROUTING -o eth0 -s 10.175.0.0/24 -j
MASQUERADE

which I thought would masquerade *only* traffic from the 10.175.0.0/24
subnet through eth0, but that didn;t work (and looking at it closer, I
am able to see why)

Any help appreciated.

TIA. I look forward to hearing fromyou.

-Alan

SilkBC <swasak@hotmail.com> wrote:
> Hello,

> How do you tell IPTables to not masquerade several specific subnets,
> or alternatively, masquerade *only* one specific subnet but not
> everything else?

> We have several remote sites with the following subnets:

> site1 (main office): 10.175.0.0/24
> site2 (remote): 10.175.1.0/24
> site3 (remote): 10.175.2.0/24
> site4 (remote): 10.175.3.0/24

> We are wanting to run full two-way site-to-site VPNs between the
> remote sites and the main office. We are able to get one tunnel
> working properly, but the others, while the tunnels are indeed up, we
> cannot ping across to them from the main office. The VPN is IPSec.

> Here is the current masquerading rule (on the main office firewall/
> gateway), which is allowing the one IPSec tunnel to work no problem:

> iptables -t nat -A POSTROUTING -o eth0 -d ! 10.175.1.0/24 -j
> MASQUERADE

> which is saying to masquerade all traffic going through eth0 *except*
> for traffic destined for the 10.175.1.0/24 network.

> IPSec does not create it's own interface unfortunately, but rather
> "shares" eth0.

> I have tried this rule:

> iptables -t nat -A POSTROUTING -o eth0 -s 10.175.0.0/24 -j
> MASQUERADE

Given that I'm no IPSec or iptables expert, you might try this:

iptables -t nat -A POSTROUTING -o eth0 -d ! 10.175.0.0/16 -j MASQUERADE

It would seem to masquerade all traffic output through eth0 except
that to the VPNs, assuming no traffic to 10.175.0.0/24 goes out eth0.
But since my view of eth0/IPSec VPN/"shares" is cloudy at best that
assumption could easily be wrong.

> which I thought would masquerade *only* traffic from the 10.175.0.0/24
> subnet through eth0, but that didn;t work (and looking at it closer, I
> am able to see why)

> Any help appreciated.

> TIA. I look forward to hearing fromyou.

> -Alan


--
Clifford Kite
/* I hear and I forget. I see and I remember. I do and I understand.
--Confucius, 551-479 BC */

On Mar 27, 1:46 pm, Clifford Kite <k...@not.available.tld> wrote:
> Given that I'm no IPSec or iptables expert, you might try this:
>
> iptables -t nat -A POSTROUTING -o eth0 -d ! 10.175.0.0/16 -j MASQUERADE

I had considered the above, but thought it would have prevented the
LAN traffic at the main site (10.175.0.0/24) from being masquerated/
nat'd out to the Internet. I gave it a try anyway, and it doesn't
seem to affect that traffic.

Having done that, I have made some progress: from the 10.175.0.0/24
(main site) network, I am able to ping the private gateway IPs of the
routers at the different sites (10.175.x.254) whereas I was not able
to do so previously. I am unable to ping any of the PCs behind the
gateways, however (though I can do so if I SSH to the gateway itself
and start pinging the IPs of the PCs).

I was thinking this may be a routing issue until I was actually able
to ping just one of the PCs in the 10.175.3.0/24 subnet, though I
cannot ping any of the others behind it.

The firewall is not an issue, as it is running the exact same one as
the site with the 10.175.1.0/24 subnet (which is working 100% as it
should). The routing tables are also exactly the same, except for the
local subnet and of course the ISP gateway they have to go through.

Open to any other suggestions... :-)

-Alan M.

SilkBC <swasak@hotmail.com> wrote:
> On Mar 27, 1:46 pm, Clifford Kite <k...@not.available.tld> wrote:
>> Given that I'm no IPSec or iptables expert, you might try this:
>>
>> iptables -t nat -A POSTROUTING -o eth0 -d ! 10.175.0.0/16 -j MASQUERADE

> I had considered the above, but thought it would have prevented the
> LAN traffic at the main site (10.175.0.0/24) from being masquerated/
> nat'd out to the Internet. I gave it a try anyway, and it doesn't
> seem to affect that traffic.

> Having done that, I have made some progress: from the 10.175.0.0/24
> (main site) network, I am able to ping the private gateway IPs of the
> routers at the different sites (10.175.x.254) whereas I was not able
> to do so previously. I am unable to ping any of the PCs behind the
> gateways, however (though I can do so if I SSH to the gateway itself
> and start pinging the IPs of the PCs).

> I was thinking this may be a routing issue until I was actually able
> to ping just one of the PCs in the 10.175.3.0/24 subnet, though I
> cannot ping any of the others behind it.

> The firewall is not an issue, as it is running the exact same one as
> the site with the 10.175.1.0/24 subnet (which is working 100% as it
> should). The routing tables are also exactly the same, except for the
> local subnet and of course the ISP gateway they have to go through.

> Open to any other suggestions... :-)

It smacks of the lack of IP forwarding on the VPN gateways, except
for the one for 10.175.1.0/24 of course. You also might enquire as to
whether there is anything special about the PC that responds to pinging.
That seems to contradict my suggestion: if IP forwarding is missing
on the gateway then no PC should respond and if it isn't then all PCs
should respond.

Anyway, since 10.175.1.0/24 is still 100% with the new rule it seems
like the other subnets should also work with it.

corncob:~# cat /proc/sys/net/ipv4/ip_forward
1

> -Alan M.


--
Clifford Kite