ipsec and iptables

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:

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

Ciao.

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)

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

Yes.

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

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.

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

Hi Marco,

thanks for your help so far. Some additional questions:

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

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

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