[Firewall] Fix in 50ipsec-vpn.plugin

Philip Prindeville philipp_subx at redfish-solutions.com
Wed Jan 14 00:32:00 CET 2009


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