2.6 native IPsec implementation question

2.6 native IPsec implementation question

[Blizbor]

Greetings,

I hope, this is right place to ask my questions.

1. Why IPsec in 2.6 doesn't uses separate interface ?
It makes impossible to implement firewall logic like this (or I'm 
missing something):

incoming from eth0 allow AH
incoming from eth0 allow ESP
incoming from eth0 allow udp 500
incoming from eth0 allow udp 53
incoming from eth0 allow ICMP related
incoming from eth0 deny all

then set of filters restricting traffic incoming via IPsec for examle:
incoming from ipsec0 allow tcp 389
incoming from ipsec0 allow ICMP related
incoming from ipsec0 deny all

(please consider roadwarrior client with not known IP address)

2. Why IPsec in 2.6 doesn't creates entries in the route tables ?
It's a bit confusing when 'ip route list' doesnt makes you aware that
some traffic is going somwhere else than defined in route tables.

(you must know that there is IPsec in use on the host, then you are using
setkey to list rules, and then you must analyse rules to catch routes - 
ugly solution.)


Reards,
Blizbor

Re: 2.6 native IPsec implementation question

[Jan Engelhardt]

>1. Why IPsec in 2.6 doesn't uses separate interface ?
>It makes impossible to implement firewall logic like this (or I'm
>missing something):
>
>incoming from eth0 allow AH
>incoming from eth0 allow ESP
>incoming from eth0 allow udp 500
>incoming from eth0 allow udp 53
>incoming from eth0 allow ICMP related
>incoming from eth0 deny all

iptables -A INPUT -N myipsec;
iptables -A INPUT -j myipsec -i eth0 -m ah
iptables -A INPUT -j myipsec -i eth0 -m esp
iptables -A INPUT -j ACCEPT -i eth0 -p udp --dport 53
iptables -A INPUT -j ACCEPT -i eth0 -p udp --dport 500
iptables -A INPUT -j ACCEPT -i eth0 -p icmp -m state --state RELATED
iptables -A INPUT -j REJECT -i eth0

>then set of filters restricting traffic incoming via IPsec for examle:
>incoming from ipsec0 allow tcp 389
>incoming from ipsec0 allow ICMP related
>incoming from ipsec0 deny all

iptables -A myipsec -j ACCEPT -p tcp --dport 389
iptables -A myipsec -j ACCEPT -p icmp -m state --state RELATED
iptables -A myipsec -j REJECT

Maybe that solves it? (Not sure whether the myipsec chain works as thought.)

>2. Why IPsec in 2.6 doesn't creates entries in the route tables ?

Because it doesnot create a device ipsecN?




Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de

Re: 2.6 native IPsec implementation question

[Blizbor]

;) My question wasn't "how does ipsec rules looks" but "why its 
implemented such a way".
These almost exactly are rules I want to implement.
But, when you run tcpdump -nni eth0 you can see ESP traffic _and_ one 
direction of something going through IPsec.
Imagine, that on eth0 five IPsec tunnels are "ended" and only one I wish 
to allow tcp/389.
It seems not possible to just allow tcp/389 from only one VPN because IP 
addresses are changing daily
in all 5 remote locations.
Moreover "-i eth0 -j DROP" blocks IPsec traffic ... (or -o eth0 i don't 
remember direction)


Jan Engelhardt wrote:

>>2. Why IPsec in 2.6 doesn't creates entries in the route tables ?
>>    
>>
>
>Because it doesnot create a device ipsecN?
>  
>
And thats the issue - WHY it is implemented such a way ?
Which developement considerations caused that choice ?

Regards,
Blizbor

Re: 2.6 native IPsec implementation question

[Jan Engelhardt]

>These almost exactly are rules I want to implement.
>But, when you run tcpdump -nni eth0 you can see ESP traffic _and_ one
>direction of something going through IPsec.

I think that PF_PACKETs "bypass" the firewall. Don't count on that, though.
(It's because I still see incoming port attempts despite having a tight
-P DROP)

>Moreover "-i eth0 -j DROP" blocks IPsec traffic ... (or -o eth0 i don't
>remember direction)

You "sit" on the network card chip and then think of input and output.
Btw, -j DROP will only drop what has not been matched up to now. So if you get
to -j ACCEPT IPsec traffic beforehand (I think -m ah / -m esp, did not
it?), they will never reach -j DROP.



Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de

Re: 2.6 native IPsec implementation question

[Blizbor]

Jan Engelhardt wrote:

>You "sit" on the network card chip and then think of input and output.
>Btw, -j DROP will only drop what has not been matched up to now. So if you get
>to -j ACCEPT IPsec traffic beforehand (I think -m ah / -m esp, did not
>it?), they will never reach -j DROP.
>  
>
No, it's not like you think.

Situation is NOT EASY IF you have ONE VPN.
Just "close" eth0 for anything, allow AH,ESP,DNS from "any" IP addres,
then how you detect if tcp/389 is from VPN or form world ? You cant.
To make things harder - there are eth0, eth1, eth2 and eth3, two of them
has public IP addresses, two has private IP addresses, there is IPsec VPN
server running on both public addresses and a lot (32) of roadwarrior VPN
clients.

So, in this not easy situation firewalling is not possible.
Believe me.

But, how to implement firewall using iptables command is not my issue.
Lets assume that I just want to do "mrtg" traffic accounting....

So, my questions are still actual.

Regards,
Blizbor

Re: 2.6 native IPsec implementation question

[Andreas Unterkircher]

FYI: openswan is working on a rebirth of klips (ipsecX interfaces)
for 2.6 kernels

http://www.openswan.org/

Andi

Am Montag, den 15.11.2004, 14:44 +0100 schrieb Blizbor:
> Greetings,
> 
> I hope, this is right place to ask my questions.
> 
> 1. Why IPsec in 2.6 doesn't uses separate interface ?
> It makes impossible to implement firewall logic like this (or I'm 
> missing something):
> 
> incoming from eth0 allow AH
> incoming from eth0 allow ESP
> incoming from eth0 allow udp 500
> incoming from eth0 allow udp 53
> incoming from eth0 allow ICMP related
> incoming from eth0 deny all
> 
> then set of filters restricting traffic incoming via IPsec for examle:
> incoming from ipsec0 allow tcp 389
> incoming from ipsec0 allow ICMP related
> incoming from ipsec0 deny all
> 
> (please consider roadwarrior client with not known IP address)
> 
> 2. Why IPsec in 2.6 doesn't creates entries in the route tables ?
> It's a bit confusing when 'ip route list' doesnt makes you aware that
> some traffic is going somwhere else than defined in route tables.
> 
> (you must know that there is IPsec in use on the host, then you are using
> setkey to list rules, and then you must analyse rules to catch routes - 
> ugly solution.)
> 
> 
> Reards,
> Blizbor
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/