[Firewall] Fix in 50ipsec-vpn.plugin

Philip A. Prindeville philipp_subx at redfish-solutions.com
Mon Jan 12 18:39:38 CET 2009


That has the source and destination networks backwards.  This is 
outbound traffic, after all.

Source will be $INTERNAL_NET, and destination will be $IPSEC_VPN_NETS 
when -o is $eif.

But like I said, that means that any remote network can spoof 
packets.... the way I originally submitted meant that the addresses had 
to correspond to the actual SA pairings, which is much more secure.


Arno van Amersfoort wrote:
> Well, I've changed it into something a little nicer IMHO:
>
> for vnet1 in $IPSEC_VPN_NETS; do
> $IPTABLES -A INPUT -i $eif -d $vnet1 -m mark --mark 1 -j ACCEPT
> for vnet2 in $INTERNAL_NET; do
> # Avoid the problem of LAN packets being NAT'ed/masqueraded:
> $IPTABLES -t nat -A POSTROUTING -o $eif -s $vnet1 -d $vnet2 -j ACCEPT
> done
> done
>
>
> but are you sure you don't want it like:
>
> for vnet1 in $IPSEC_VPN_NETS; do
> $IPTABLES -A INPUT -i $eif -d $vnet1 -m mark --mark 1 -j ACCEPT
> for vnet2 in $INTERNAL_NET; do
> # Avoid the problem of LAN packets being NAT'ed/masqueraded:
> $IPTABLES -t nat -A POSTROUTING -o $eif -s $vnet1 -d $vnet2 -j ACCEPT
> done
> for vnet3 in $IPSEC_VPN_NETS; do
> $IPTABLES -t nat -A POSTROUTING -o $eif -s $vnet1 -d $vnet3 -j ACCEPT
> done
> done
>
> ???
>
> a.
>
>
> Philip A. Prindeville wrote:
>> Philip A. Prindeville wrote:
>>> Please include this patch.
>>>
>>> Currently $IPSEC_VPN_NETS is a list of networks that aren't local 
>>> but for whom we have connections (i.e. something apart from 
>>> $INTERNAL_NET).
>>>
>>> This was not how we were using it. The loop:
>>>
>>> for vnet1 in $IPSEC_VPN_NETS; do
>>> $IPTABLES -A INPUT -i $eif -d $vnet1 -m mark --mark 1 -j ACCEPT
>>> for vnet2 in $IPSEC_VPN_NETS; do
>>> # Avoid the problem of LAN packets being NAT'ed/masqueraded:
>>> $IPTABLES -t nat -A POSTROUTING -o $eif -s $vnet1 -d $vnet2 -j ACCEPT
>>> done
>>> done
>>>
>>>
>>> would presuppose that $IPSEC_VPN_NETS included both local and remote 
>>> nets, since it was using them in the "-s" argument on outbound 
>>> packets (i.e. -o $eif).
>>>
>>> This was wrong. There were two solutions to this logic.
>>>
>>> One is that the source address should come from $INTERNAL_NET.... 
>>> but you might not want to export all of your subnets to all other 
>>> VPN peers.
>>
>> In case it wasn't clear, the rewrite would have been:
>>
>> for vnet1 in $IPSEC_VPN_NETS; do
>> $IPTABLES -A INPUT -i $eif -d $vnet1 -m mark --mark 1 -j ACCEPT
>> done
>>
>> for vnet1 in $INTERNAL_NET; do
>> for vnet2 in $IPSEC_VPN_NETS; do
>> # Avoid the problem of LAN packets being NAT'ed/masqueraded:
>> $IPTABLES -t nat -A POSTROUTING -o $eif -s $vnet1 -d $vnet2 -j ACCEPT
>> done
>> done
>>
>>
>> -Philip
>>
>>
>>>
>>> The other solution was to replace IPSEC_VPN_NETS with 
>>> IPSEC_VPN_ASSOCS, which is a tuple of sets of subnets (local,remote) 
>>> which exchange packets.
>>>
>>> I.e.:
>>>
>>> IPSEC_VPN_ASSOCS="
>>> 192.168.1.0/24,192.168.2.0/24:172.16.0.0/16,172.17.0.0/16,172.18.0.0/16
>>> 192.168.2.0/24:10.0.0.0/8
>>> "
>>>
>>> means that local networks 192.168.1.0/24 and 192.168.2.0/24 are 
>>> routable to 172.16.0.0/16, 172.17.0.0/16, and 172.18.0.0/16, but 
>>> that network 192.168.2.0/24 only is advertised to 10.0.0.0/8 (i.e. 
>>> 192.168.1.0/24 is absent).
>>>
>>> Thanks,
>>>
>>> -Philip
>>>
>>>



More information about the Firewall mailing list