[Openswan Users] OpenSWAN Firewall Transport & Tunnel

JCotton jcotton1123 at gmail.com
Tue Nov 23 11:05:22 EST 2010


Let me ask then, why does my firewall policy work? And why doesn't "--mode
tunnel" work in the INPUT chain?

On Tue, Nov 23, 2010 at 10:21 AM, Paul Wouters <paul at xelerance.com> wrote:

> On Tue, 23 Nov 2010, JCotton wrote:
>
>  Below I have extracted the relevant firewall rules. The below ruleset
>> works however I do not understand why I have to set
>> "--mode transport" in the INPUT chain instead of "--mode tunnel". If I
>> set"--mode = tunnel" I cannot ping the gateway or the
>> hosts behind that gateway. I have been looking for documentation
>> explaining how netfilter and ipsec stack work together but
>> the only docs I have found have been vague (including the wiki).
>>
>> Setup:
>> Our setup is far from ideal but I had to wok with what we had.
>> Subnet -> Openswan(NAT,172.16.0.0/24) -> Cable Modem (NAT, 10.1.1.0/24)
>> -> Internet <- Cable Modem (NAT, 10.1.10.0/24) <-
>> Openswan(NAT, 172.16.2.0/24) <- Subnet
>>
>
> A subnet to subnet connection is always tunnel mode (which is also the
> default for openswan unless
> type=transport is defined. You in fact ,specify that default type=tunnel
> explicitely.
>
> The "transport" you see in the ip xfrm output are not for the SA endpoints.
> I *think* they
> are for the "ipsec firewall" that Openswan does not use, and you'll see
> them for the "0.0.0.0/0
> ranges only.
>
> Paul
>
>
>  ----------------------------------------------------------
>> # IPSec (IKE, ESP, NAT-T)
>> $IPTABLES -A INPUT -p udp --dport 500 -j ACCEPT
>> $IPTABLES -A INPUT -p esp -j ACCEPT
>> $IPTABLES -A INPUT -p udp --dport 4500 -j ACCEPT
>>
>> # Accept connections from various subnets
>> $IPTABLES -A INPUT -i $INT_INF -s 172.16.2.0/24 -m state --state NEW -j
>> ACCEPT
>> #$IPTABLES -A INPUT -m policy --dir in --pol ipsec --mode tunnel
>> --tunnel-src 172.16.0.0/24 -j ACCEPT
>> #$IPTABLES -A INPUT -m policy --dir in --pol ipsec --mode tunnel
>> --tunnel-src 172.16.1.0/24 -j ACCEPT
>> #$IPTABLES -A INPUT -m policy --dir in --pol ipsec --mode tunnel -j ACCEPT
>> $IPTABLES -A INPUT -m policy --dir in --pol ipsec --mode transport -j
>> ACCEPT
>>
>>
>> # Allow forwarding of connections for  various subnetworks
>> $IPTABLES -A FORWARD -i $INT_INF -s 172.16.2.0/24 -m state --state NEW -j
>> ACCEPT
>> $IPTABLES -A FORWARD -m policy --dir in --pol ipsec --mode tunnel -s
>> 172.16.0.0/24 -j ACCEPT
>> $IPTABLES -A FORWARD -m policy --dir in --pol ipsec --mode tunnel -s
>> 172.16.1.0/24 -j ACCEPT
>>
>>
>> -----------------------------------------------------------------------
>> ip xfrm policy:
>> src 172.16.1.0/24 dst 172.16.2.0/24
>>         dir in priority 2344
>>         tmpl src xx.xx.xx.xx dst 10.1.1.3
>>                 proto comp reqid 16386 mode tunnel
>>                 level use
>>         tmpl src 0.0.0.0 dst 0.0.0.0
>>                 proto esp reqid 16385 mode transport
>> src 172.16.1.0/24 dst 172.16.2.0/24
>>         dir fwd priority 2344
>>         tmpl src xx.xx.xx.xx dst 10.1.1.3
>>                 proto comp reqid 16386 mode tunnel
>>                 level use
>>         tmpl src 0.0.0.0 dst 0.0.0.0
>>                 proto esp reqid 16385 mode transport
>> src 172.16.2.0/24 dst 172.16.1.0/24
>>         dir out priority 2344
>>         tmpl src 10.1.1.3 dst 68.57.21.118
>>                 proto comp reqid 16386 mode tunnel
>>         tmpl src 0.0.0.0 dst 0.0.0.0
>>                 proto esp reqid 16385 mode transport
>> src 172.16.0.0/24 dst 172.16.2.0/24
>>         dir in priority 2344
>>         tmpl src xx.xx.xx.xx dst 10.1.1.3
>>                 proto comp reqid 16390 mode tunnel
>>                 level use
>>         tmpl src 0.0.0.0 dst 0.0.0.0
>>                 proto esp reqid 16389 mode transport
>> src 172.16.0.0/24 dst 172.16.2.0/24
>>         dir fwd priority 2344
>>         tmpl src xx.xx.xx.xx dst 10.1.1.3
>>                 proto comp reqid 16390 mode tunnel
>>                 level use
>>         tmpl src 0.0.0.0 dst 0.0.0.0
>>                 proto esp reqid 16389 mode transport
>> src 172.16.2.0/24 dst 172.16.0.0/24
>>         dir out priority 2344
>>         tmpl src 10.1.1.3 dst xx.xx.xx.xx
>>                 proto comp reqid 16390 mode tunnel
>>         tmpl src 0.0.0.0 dst 0.0.0.0
>>                 proto esp reqid 16389 mode transport
>>
>> ----------------------------------------------------------------
>> ipsec.conf:
>> version 2.0
>>
>> config setup
>>         interfaces=%defaultroute
>>         protostack=netkey
>>         nat_traversal=yes
>>         virtual_private=%v4:
>> 10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/24,$v:!172.16.2.0/24<http://10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/24,$v:%21172.16.2.0/24>
>>         nhelpers=0
>>
>> conn conn1
>>         type=tunnel
>>         authby=secret
>>         pfs=yes
>>         ike=aes256-sha1-1536
>>         esp=aes256-sha1-1536
>>         keyexchange=ike
>>         compress=yes
>>         keyingtries=3
>>         rekey=yes
>>         dpddelay=30
>>         dpdtimeout=30
>>         dpdaction=restart
>>         left=10.1.1.3
>>         leftid=@ID
>>         leftsourceip=172.16.2.1
>>         leftsubnet=172.16.2.0/24
>>         right=xx.xx.xx.xx
>>         rightid=@ID
>>         rightsourceip=172.16.0.1
>>         rightsubnet=172.16.0.0/24
>>         auto=start
>>
>> *connection 2 is identical to the 1st except for the ids & subnets
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20101123/e58437b8/attachment-0001.html 


More information about the Users mailing list