ipsec and iptables...

ipsec and iptables...

[dimitri borjac]

Hi,

do you know where i can find any interesting documentation about the 
interoperability/compatibility of ipsec with iptables ...?
and more precisely regarding the eventual UDP encapsulation (NAT-T) and the 
pass-through technology used for VPN ?

any link or help would be appreciated :)
thanks !

Dimo

_________________________________________________________________
Hotmail : un compte GRATUIT qui vous suit partout et tout le temps ! 
http://g.msn.fr/FR1000/9493

ipsec and iptables

[Andreas Stallmann]

Hello,

this is somehow a continuation of a thread I started in 
lists.openswan.org, which was probably a little bit off-topic there, and 
  might be more on topic here, as it is mainly iptables related.

The short story:

I'm looking for for in-depth documentation for the iptables "ipsec 
policy match" module. It might be just the right thing to solve my 
iptables/ipsec-problems; but the information given with "iptables -m 
policy -h" is not very intuitive.

The long story:

In the good old times of super-freeswan and kernel 2.4 I was a happy 
user of ipsec interfaces. These allowed me to define rules like that:

1. $IPTABLES -A INPUT -p udp --dport isakmp -d $FIREWALL_EXT_IP -j ALLOW
2. $IPTABLES -A INPUT -p esp -d $FIREWALL_EXT_IP -j ALLOW
3. $IPTABLES -A INPUT -i ipsec0 -d $INTERNAL_NET -j ALLOW

(All with stateful inspection switched on.)

This, filtering traffic based on the fact, that it came from the ipsec 
interface and thus was "authenticated" somehow, is something I miss in 
the current OpenSWAN implementation (and, yes, the compilation of the 
module fails with the current 2.6 kernel).

Thus I allow all AH/ESP-traffic to the firewall, like above in 1. and 2.
How do I write rule no. 3 now, without ipsec interfaces at hand? How do 
I filter what's originating from the ipsec-stack, and is directed to the 
local net? I allready know, that the "ipsec policy match" module might 
bring me further, I even received a suggestion for a rule:

 > $IPTABLES -A FORWARD  -m policy --dir in -i eth2 --pol  ipsec \
 > -m state --state NEW  -j ACCEPT

OK, let's do some naive painting. In the following picture, my packet 
"X" has passed the rules 1 and 2 on the INPUT chain, allowing it to pass 
through to the OPENSWAN-Software. It got authenticated by openswan and 
is now passed back to the iptables stack.

outside------->FORWARD--------->inside
        |                    |
      INPUT                OUTPUT
        |_____(OPENSWAN)_X___|

How would the firewall rule look, that allowed the packet to go right 
through to my internal net? Like stated above? What I do not understand, 
is that the rule is appending to the FORWARD chain, but isn't the packet 
coming from the inside of the firewall, because it has passed an 
internal process, and thus should append to the OUTPUT chain? Or is it 
passed back to the forward chain, because after "unwrapping", it's 
header identifies it as a packed coming from an external private subnet, 
being directed to a internal private subnet?

And is the packet somehow "marked" by openswan, so that iptables "knows" 
it passed through? How does this whole "match policy" stuff actually 
work, by the way?

I allready read through most of the HOWTOS on netfilter.org again; but 
as of now, I did not find anything related to my problem.

Well, folks, I know I deserve a RTFM - but please let me know, where I 
find the FM! Now it "pays back", that I haven't done IPSEC on the 
commandline for such a long time (I'm using fwbuilder, silly me!). :-(

Thanks in advance,

A.
-- 
dawin GmbH - Andreas Stallmann - Consultant
http://www.dawin.de

RE: ipsec and iptables

[Marco Berizzi]

Andreas Stallmann wrote:

>Hello,

Ciao.

>3. $IPTABLES -A INPUT -i ipsec0 -d $INTERNAL_NET -j ALLOW
>How do I write rule no. 3 now, without ipsec interfaces at hand?

Here is an example: policy match is much more flexible than ipsecX
virtual interface. You can even select ipsec traffic from different
gateway.

iptables -A FORWARD -m policy \

--dir in \ this is for select inbound/outbound traffic

--pol ipsec \ this match if traffic is subject to IPsec processing

--mode tunnel \ this is if you want to match tunnel mode

--tunnel-dst 172.16.1.247 --tunnel-src 172.16.1.226 \
             ^^^^^^^^^^^               ^^^^^^^^^^^^
These are the ipsec endpoint addresses (usually public ip addresses)

-s blablab -d $INTERNAL_NET --protocol blabla --dport blabla \
what you want to do with this rule

-j ACCEPT (or DROP)

>OK, let's do some naive painting. In the following picture, my packet "X" 
>has passed the rules 1 and 2 on the INPUT chain, allowing it to pass 
>through to the OPENSWAN-Software. It got authenticated by openswan and is 
>now passed back to the iptables stack.

No. Openswan has nothing to do with this schema. Openswan (when used
with netkey) is only an IKE daemon.

>outside------->FORWARD--------->inside
>        |                    |
>      INPUT                OUTPUT
>        |_____(OPENSWAN)_X___|
>

>Or is it passed back to the forward chain, because after "unwrapping", it's 
>header identifies it as a packed coming from an external private subnet, 
>being directed to a internal private subnet?

Yes.

ipsec and iptables

[Mark L. Wise]

Marco,

I see your response to Andreas regarding ipsec and tables.

I have a similar problem/question.

I replaced RH9 with FC4 for my firewalls.  Setting up the ipsec tunnel went
fine.  I can send packets between two private networks.  However, when I
enable NAT so that the internal nets can get to the internet, then the ipsec
VPN fails.

Here is the configuration:

192.168.20.0/24(net)-->[192.168.20.2(gw)-->$PUBLICIP1 <firewall # 1>]  ....
internet
.... internet [<firewall # 2>
$PUBLICIP2<--192.168.30.100(gw)<--192.168.30.0/24(net)

Without NAT, all packets can reach every destination internally.  When I add
the following to allow NAT to allow the internal machines access to the
internet, packets are no longer routed to the opposite local net;

iptables -t nat -A POSTROUTING -d ! 192.168.30.0/24 -j SNAT --to-source
$PUBLICIP1

How can I route outgoing packets going to 192.168.30.0/24 (opposite internal
net) differently than packets going to other addresses????

TIA,

Mark

Mark L. Wise, President
Alpha II Service, Inc.
1312 Epworth Ave
Reynoldsburg, Ohio 43068-2116
614 868-5033 (Phone)
614 868-1060 (Fax)

RE: ipsec and iptables

[Eduardo Spremolla]

I use a trick stste on ipsec-tools howto:

iptables -t mangle -A PREROUTING -i eth0 -p esp -j MARK --set-mark 1

then to catch the uncapsulated packet:

iptables -A INPUT -m mark --mark 1 -j ACCEPT



On Tue, 2006-02-14 at 14:39 +0100, Marco Berizzi wrote:
> Andreas Stallmann wrote:
> 
> >Hello,
> 
> Ciao.
> 
> >3. $IPTABLES -A INPUT -i ipsec0 -d $INTERNAL_NET -j ALLOW
> >How do I write rule no. 3 now, without ipsec interfaces at hand?
> 
> Here is an example: policy match is much more flexible than ipsecX
> virtual interface. You can even select ipsec traffic from different
> gateway.
> 
> iptables -A FORWARD -m policy \
> 
> --dir in \ this is for select inbound/outbound traffic
> 
> --pol ipsec \ this match if traffic is subject to IPsec processing
> 
> --mode tunnel \ this is if you want to match tunnel mode
> 
> --tunnel-dst 172.16.1.247 --tunnel-src 172.16.1.226 \
>              ^^^^^^^^^^^               ^^^^^^^^^^^^
> These are the ipsec endpoint addresses (usually public ip addresses)
> 
> -s blablab -d $INTERNAL_NET --protocol blabla --dport blabla \
> what you want to do with this rule
> 
> -j ACCEPT (or DROP)
> 
> >OK, let's do some naive painting. In the following picture, my packet "X" 
> >has passed the rules 1 and 2 on the INPUT chain, allowing it to pass 
> >through to the OPENSWAN-Software. It got authenticated by openswan and is 
> >now passed back to the iptables stack.
> 
> No. Openswan has nothing to do with this schema. Openswan (when used
> with netkey) is only an IKE daemon.
> 
> >outside------->FORWARD--------->inside
> >        |                    |
> >      INPUT                OUTPUT
> >        |_____(OPENSWAN)_X___|
> >
> 
> >Or is it passed back to the forward chain, because after "unwrapping", it's 
> >header identifies it as a packed coming from an external private subnet, 
> >being directed to a internal private subnet?
> 
> Yes.
> 
> 
> 


Este e-mail y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información.
. . . . . . . . .
This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.

RE: ipsec and iptables

[Marco Berizzi]

Mark L. Wise wrote:

>Here is the configuration:
>
>192.168.20.0/24(net)-->[192.168.20.2(gw)-->$PUBLICIP1 <firewall # 1>]  ....
>internet
>.... internet [<firewall # 2>
>$PUBLICIP2<--192.168.30.100(gw)<--192.168.30.0/24(net)
>
>Without NAT, all packets can reach every destination internally.  When I 
>add
>the following to allow NAT to allow the internal machines access to the
>internet, packets are no longer routed to the opposite local net;
>
>iptables -t nat -A POSTROUTING -d ! 192.168.30.0/24 -j SNAT --to-source
>$PUBLICIP1

mhhh... what linux kernel version are you using?  There are some know issue
when you try to snat esp packet with linux < 2.6.15-git8

>How can I route outgoing packets going to 192.168.30.0/24 (opposite 
>internal
>net) differently than packets going to other addresses????

Try these rule:

iptables -t nat -A POSTROUTING -s 192.168.20.0/24 -d 192.168.30.0/24 -j 
ACCEPT
iptables -t nat -A POSTROUTING --protocol esp -j ACCEPT (don't snat ipsec 
packets)

iptables -t nat -A POSTROUTING --protocol tcp -j SNAT --to-source $PUBLICIP1
iptables -t nat -A POSTROUTING --protocol udp -j SNAT --to-source $PUBLICIP1

Ciao

RE: ipsec and iptables

[Marco Berizzi]

Eduardo Spremolla wrote:

>I use a trick stste on ipsec-tools howto:
>
>iptables -t mangle -A PREROUTING -i eth0 -p esp -j MARK --set-mark 1
>
>then to catch the uncapsulated packet:
>
>iptables -A INPUT -m mark --mark 1 -j ACCEPT

Yes. There are many way to filter ipsec packets. However
I think that the proper way to filter ipsec packets is the
policy match with recent kernel (2.6.16) and iptables (1.3.5).

Ciao

Re: ipsec and iptables

[Andreas Stallmann]

Hi Marco,

thanks for your help so far. Some additional questions:

Marco Berizzi wrote:
> --tunnel-dst 172.16.1.247 --tunnel-src 172.16.1.226 \
>             ^^^^^^^^^^^               ^^^^^^^^^^^^
> These are the ipsec endpoint addresses (usually public ip addresses)
Can I leave those out? My endpoints do both have dynamical addresses, 
cause one is a roadwarrior, and the other a firewall, which is connected 
to the internet via ADSL and receives a new address each 24h.

Thank you again,

Andreas

-- 
dawin GmbH - Andreas Stallmann - Consultant
Belgische Allee 50 - 53842 Troisdorf
FON +49 (0)2241 / 39 71 98 - 0
FAX +49 (0)2241 / 39 71 98 - 9

Re: ipsec and iptables

[Marco Berizzi]

Andreas Stallmann wrote:

>Hi Marco,
>
>thanks for your help so far. Some additional questions:
>
>Marco Berizzi wrote:
>>--tunnel-dst 172.16.1.247 --tunnel-src 172.16.1.226 \
>>             ^^^^^^^^^^^               ^^^^^^^^^^^^
>>These are the ipsec endpoint addresses (usually public ip addresses)
>Can I leave those out?

I think yes. I think also you may specify 0.0.0.0 for all ip.

>My endpoints do both have dynamical addresses, cause one is a roadwarrior, 
>and the other a firewall, which is connected to the internet via ADSL and 
>receives a new address each 24h.

If you are using swan as IKE daemon you may insert dynamically
these rule with left(right)updown script.