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
>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, http://www.gwdg.de
;) 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
>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, http://www.gwdg.de
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/