[Firewall] Fix in 50ipsec-vpn.plugin

Philip A. Prindeville philipp_subx at redfish-solutions.com
Thu Jan 15 07:57:46 CET 2009


Thanks, that works.

I'm now building astlinux trunk with the nightlies...  how long before 
this fix finds its way into a numbered release?

-Philip

Arno van Amersfoort wrote:
> Dear Philip,
>
> Thanks for pointing that out I've updated the plugin accordingly.
>
> cheers,
>
> Arno
>
> Philip Prindeville wrote:
>> I'm looking at the nightly build tarball, and seeing:
>>
>>  IFS=' ,'
>>  for eif in $EXT_IF; do
>>    # Allow IPSEC packets in
>>    $IPTABLES -t mangle -A PREROUTING -i $eif -p esp -j MARK --set-mark 1
>>
>>    $IPTABLES -A FORWARD -i $eif -m mark --mark 1 -j ACCEPT
>>    $IPTABLES -A FORWARD -o $eif -m mark --mark 1 -j ACCEPT
>>
>>    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
>>  done
>>
>>
>> This last invocation of $IPTABLES is still wrong.
>>
>> It should be:
>>
>> $IPTABLES -t nat -A POSTROUTING -o $eif -s $vnet2 -d $vnet1 -j ACCEPT
>>
>> and not ... -s $vnet1 -d $vnet2 ...
>>
>> -Philip
>>
>>
>>
>> Philip A. Prindeville wrote:
>>> 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