Re: Handling RoadWarrior VPN Traffic with IPtables

Re: Handling RoadWarrior VPN Traffic with IPtables

[Henrique Netfilter]

Jan,

This really looks like might work. I read iptables man page and sounds 
pretty logical.
I'm gonna test it, and then I'll reply here saying if it worked or not.
So far, thank you.



Jan Engelhardt wrote:
> On Friday 2008-04-25 17:05, Henrique Netfilter wrote:
>   
>> The l2tpd is encaspuled inside the ESP traffic of the IPSec tunnel,
>> and when it reaches my external interface, it must be redirected to
>> my internal interface (where the l2tpd daemon listens) to continue
>> the connection. If I had a KLIPS kernel, I could easily just DNAT
>> the incoming L2TP requisition on interface ipsec0 to my internal
>> interface:
>>
>> iptables -t nat -A PREROUTING -i ipsecX -p udp --sport 1701 --dport
>> 1701 -j DNAT --to-destination X.X.X.X <------ my internal interface
>> IP
>>
>> But since my kernel is NETKEY, I can't, since there is  no ipsec
>> interface, and I can't just DNAT the incoming traffic from my
>> external to my internal interface for security reasons (since I
>> want that only traffic coming from the IPSec tunnel to access the
>> l2tpd daemon).
>>     
>
> -i eth0 -m policy --dir in --pol ipsec
> [--tunnel-src theirip] [--tunnel-dst yourip]
>
> Should be able to accurately replace -i ipsecX. See the iptables
> manpage. --tunnel-src, --tunnel-dst are just for ensuring that
> you match exactly one tunnel, you can omit it if it satisfies you.
>
>   

Re: Handling RoadWarrior VPN Traffic with IPtables

[Henrique Netfilter]

Yes, it does work.
Followed the packet counter for the rule, it increases with each connection.
Thanks a lot, saved my life.

Henrique Netfilter wrote:
> Jan,
>
> This really looks like might work. I read iptables man page and sounds 
> pretty logical.
> I'm gonna test it, and then I'll reply here saying if it worked or not.
> So far, thank you.
>
>
>
> Jan Engelhardt wrote:
>> On Friday 2008-04-25 17:05, Henrique Netfilter wrote:
>>  
>>> The l2tpd is encaspuled inside the ESP traffic of the IPSec tunnel,
>>> and when it reaches my external interface, it must be redirected to
>>> my internal interface (where the l2tpd daemon listens) to continue
>>> the connection. If I had a KLIPS kernel, I could easily just DNAT
>>> the incoming L2TP requisition on interface ipsec0 to my internal
>>> interface:
>>>
>>> iptables -t nat -A PREROUTING -i ipsecX -p udp --sport 1701 --dport
>>> 1701 -j DNAT --to-destination X.X.X.X <------ my internal interface
>>> IP
>>>
>>> But since my kernel is NETKEY, I can't, since there is  no ipsec
>>> interface, and I can't just DNAT the incoming traffic from my
>>> external to my internal interface for security reasons (since I
>>> want that only traffic coming from the IPSec tunnel to access the
>>> l2tpd daemon).
>>>     
>>
>> -i eth0 -m policy --dir in --pol ipsec
>> [--tunnel-src theirip] [--tunnel-dst yourip]
>>
>> Should be able to accurately replace -i ipsecX. See the iptables
>> manpage. --tunnel-src, --tunnel-dst are just for ensuring that
>> you match exactly one tunnel, you can omit it if it satisfies you.
>>
>>   
>

Handling RoadWarrior VPN Traffic with IPtables

[Henrique Netfilter]

Good morning,

List, I've been trying now for some time to create a RoadWarrior VPN, 
and I finally did it.
Now I'm having some problems to tune my iptables rules to make it work 
correctly and safely.

The VPN is based on OpenSwan+l2tpd+pppd.
The distro is a Suse 10.1 kernel 2.6 (NETKEY).

The l2tpd is encaspuled inside the ESP traffic of the IPSec tunnel, and 
when it reaches my external interface, it must be redirected to my 
internal interface (where the l2tpd daemon listens) to continue the 
connection.
If I had a KLIPS kernel, I could easily just DNAT the incoming L2TP 
requisition on interface ipsec0 to my internal interface:

iptables -t nat -A PREROUTING -i ipsecX -p udp --sport 1701 --dport 1701 
-j DNAT --to-destination X.X.X.X <------ my internal interface IP

But since my kernel is NETKEY, I can't, since there is  no ipsec 
interface, and I can't just DNAT the incoming traffic from my external 
to my internal interface for security reasons (since I want that only 
traffic coming from the IPSec tunnel to access the l2tpd daemon).

At first I tought marking the ESP traffic would do the trick. I was 
wrong, since the packets marked are only those from the external peer to 
the external interface (SRC=Y.Y.Y.Y DST=Z.Z.Z.Z PROTO=ESP).

So far my last option is to apply the KLIPS patch and recompile my 
kernel, but I really would like to avoid to do so.
So I come to you, I hope that the netfilter list can help me out how to 
handle those connections using iptables.

Thank you, and so long

Henrique

Re: Handling RoadWarrior VPN Traffic with IPtables

[Jan Engelhardt]

On Friday 2008-04-25 17:05, Henrique Netfilter wrote:
>
> The l2tpd is encaspuled inside the ESP traffic of the IPSec tunnel,
> and when it reaches my external interface, it must be redirected to
> my internal interface (where the l2tpd daemon listens) to continue
> the connection. If I had a KLIPS kernel, I could easily just DNAT
> the incoming L2TP requisition on interface ipsec0 to my internal
> interface:
>
> iptables -t nat -A PREROUTING -i ipsecX -p udp --sport 1701 --dport
> 1701 -j DNAT --to-destination X.X.X.X <------ my internal interface
> IP
>
> But since my kernel is NETKEY, I can't, since there is  no ipsec
> interface, and I can't just DNAT the incoming traffic from my
> external to my internal interface for security reasons (since I
> want that only traffic coming from the IPSec tunnel to access the
> l2tpd daemon).

-i eth0 -m policy --dir in --pol ipsec
[--tunnel-src theirip] [--tunnel-dst yourip]

Should be able to accurately replace -i ipsecX. See the iptables
manpage. --tunnel-src, --tunnel-dst are just for ensuring that
you match exactly one tunnel, you can omit it if it satisfies you.