It is currently Sun Aug 19, 2018 8:19 am

All times are UTC [ DST ]




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: openl2tp + racoon interaction
PostPosted: Wed Jun 08, 2011 2:32 pm 

Joined: Sat Jun 04, 2011 9:18 am
Posts: 15
Hi Guys,

I've been scratching my eyes out trying to figure out how to set up a server for L2TP/IPSec using openl2tp and racoon for various different clients.

As it stands I can get a Linux client (also using racoon + openl2tp) working, and Windows XP. But not Windows 7.

I've tried with both the single (without ipsec.so) and multi-port (with ipsec.so) on the server side. I'd prefer the multi-port setup and this works with WinXP and Linux as it stands.

My configuration on my server, openl2tpd.conf:

Code:
ppp profile modify profile_name=default \
        optionsfile=/etc/ppp/options.l2tpd \
        clientip_as_ipparam=yes


Note that my two patches is in there, however, I don't think things are even getting to this stage just yet.

My racoon.conf:

Code:
log info;

path pre_shared_key "/etc/racoon/psk.txt";

padding {
        maximum_length 20;      # maximum padding length.
        randomize off;          # enable randomize length.
        strict_check off;       # enable strict check.
        exclusive_tail off;     # extract last one octet.
}

remote anonymous {
        exchange_mode main, aggressive;
        doi ipsec_doi;
        situation identity_only;

        nat_traversal on;
        initial_contact off;
        passive on;
        nonce_size 16;
        proposal_check obey;

        #ike_frag on;
        #esp_frag 1200;
        generate_policy on;
       # support_proxy on;

        send_cr off;
        send_cert off;

        proposal {
                encryption_algorithm aes;
                encryption_algorithm 3des;
                hash_algorithm md5;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
}

sainfo anonymous
{
        lifetime time 1 hour;
        encryption_algorithm aes;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}


Currently this results in openl2tp loading the following SAD:

Code:
41.134.75.12[any] 192.168.42.136[any] udp
        out prio def ipsec
        esp/transport//require
        created: Jun  8 14:09:57 2011  lastused:                     
        lifetime: 3600(s) validtime: 0(s)
        spid=4489 seq=1 pid=24199
        refcnt=2
192.168.42.136[any] 41.134.75.12[any] udp
        in prio def ipsec
        esp/transport//require
        created: Jun  8 14:09:57 2011  lastused:                     
        lifetime: 3600(s) validtime: 0(s)
        spid=4480 seq=2 pid=24199
        refcnt=2


which really seems wrong. Two things that look really obscure IMHO, firstly, I expect there to be port numbers there... secondly, we're working with transport mode, not tunnel mode so I really do NOT expect to see my private IP range exposed there ...

The above was spotted with the Linux client (which at the time failed to connect - it seems I need to restart both racoon and openl2tpd after attempting a connection with a Win7 box from behind the same NAT before my Linux client will function again). When the Linux works the SADP entries looks like:

Code:
41.241.240.125[47139] 41.134.75.12[40651] udp
        fwd prio def ipsec
        esp/transport//require
        created: Jun  8 14:21:41 2011  lastused:                     
        lifetime: 0(s) validtime: 0(s)
        spid=4682 seq=5 pid=26566
        refcnt=1
41.241.240.125[47139] 41.134.75.12[40651] udp
        in prio def ipsec
        esp/transport//require
        created: Jun  8 14:21:41 2011  lastused: Jun  8 14:24:48 2011
        lifetime: 0(s) validtime: 0(s)
        spid=4672 seq=6 pid=26566
        refcnt=3
41.134.75.12[40651] 41.241.240.125[47139] udp
        out prio def ipsec
        esp/transport//require
        created: Jun  8 14:21:41 2011  lastused: Jun  8 14:23:45 2011
        lifetime: 0(s) validtime: 0(s)
        spid=4665 seq=7 pid=26566
        refcnt=3


Which does NOT contain the private IPs, and have appropriate port numbers listed!

The initial SADP entries on the server is set up as:

Code:
flush;
spdflush;

spdadd 0.0.0.0/0[1701] 0.0.0.0/0 udp -P out ipsec
        esp/transport//require;

spdadd 0.0.0.0/0 0.0.0.0/0[1701] udp -P in ipsec
        esp/transport//require;


Could this be related to the modp group settings/values? I do some of this in the logs:

"ERROR: invalid DH group 20"

But I can't seem to find any fixes, other than some hints that something in xl2tp had to be changed ...

I am honestly at a loss. Any and all pointers highly appreciated!


Top
 Profile  
 
 Post subject: Re: openl2tp + racoon interaction (Win 7 issues).
PostPosted: Wed Jun 08, 2011 4:48 pm 

Joined: Sat Jun 04, 2011 9:18 am
Posts: 15
Ok, so after realizing I had a total misunderstanding re the way that racoon's config file works I'm reasonably convinced I'm not getting through the initial IPSec setup phases and that traffic _should_ be passing back and forth between Win7's and openl2tp's L2TP implementations.

For reference, here is the racoon.conf that I've now got:

Code:
log info;

path pre_shared_key "/etc/racoon/psk.txt";

padding {
        maximum_length 20;      # maximum padding length.
        randomize off;          # enable randomize length.
        strict_check off;       # enable strict check.
        exclusive_tail off;     # extract last one octet.
}

remote anonymous {
        exchange_mode main, aggressive;
        doi ipsec_doi;
        situation identity_only;

        nat_traversal on;
        initial_contact off;
        passive on;
        nonce_size 16;
        proposal_check obey;

        #ike_frag on;
        #esp_frag 1200;
        #generate_policy on;
        #support_proxy on;

        send_cr off;
        send_cert off;

        proposal {
                # Win7 pararmeters.
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
       
        proposal {
                # WinXP pararmeters.
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
       
        proposal {
                # Preferred proposal and what I use on Gentoo.
                encryption_algorithm aes;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
}

sainfo anonymous
{
        lifetime time 1 hour;
        encryption_algorithm aes, 3des;
        authentication_algorithm hmac_sha1, hmac_md5;
        compression_algorithm deflate;
}


Multiple proposals is required because the settings between Win XP and Win 7 changed. I now get SPI's allocated in both directions, indicating ESP and going over NATT. So I suspect all is now well in IPSec land. I'm now getting stuck at a different level that, and to explain what I think is happening, I've got to provide some additional information.

I've loaded the following iptables rules:

Code:
clyde ~ # iptables -L -v -n
Chain INPUT (policy DROP 7 packets, 658 bytes)
pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        esp  --  !ethlan *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4
  203 20393 LOG        udp  --  !ethlan *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
7991  660K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    2   120 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport dports 22,1723 tcp flags:0x17/0x02
   23  5920 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport dports 500,4500
    0     0 ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0           
   34  4500 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           policy match dir in pol ipsec
  408 33324 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
1028  103K LOCAL_IPS  all  --  eth+   *       0.0.0.0/0            0.0.0.0/0           
    0     0 VPN_USERS_IN  all  --  ppp+   *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 528 packets, 105K bytes)
pkts bytes target     prot opt in     out     source               destination         
  291 33590 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4
    0     0 LOG        esp  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4


Note specifically the LOG lines. Now I'm seeing this in /var/log/messages:

Code:
Jun  8 17:23:59 clyde kernel: IN=ethadsl OUT= MAC=f0:7d:68:c1:ff:d1:a4:0c:c3:62:0c:a8:08:00 SRC=41.241.240.125 DST=41.134.75.12 LEN=176 TOS=0x18 PREC=0x60 TTL=112 ID=18940 PROTO=UDP SPT=4500 DPT=4500 LEN=156
Jun  8 17:23:59 clyde kernel: IN=ethadsl OUT= MAC=f0:7d:68:c1:ff:d1:a4:0c:c3:62:0c:a8:08:00 SRC=41.241.240.125 DST=41.134.75.12 LEN=130 TOS=0x18 PREC=0x60 TTL=112 ID=18940 PROTO=UDP SPT=1701 DPT=1701 LEN=110


Which shows packets coming in over the IPSec tunnel towards L2TP. The first packet should be accepted by the inbound rule towards port 4500, the latter accepted by the ipsec policy check.

The very next such sequence is:

Code:
Jun  8 17:23:59 clyde kernel: IN= OUT=ethadsl SRC=41.134.75.12 DST=41.241.240.125 LEN=165 TOS=0x00 PREC=0x00 TTL=64 ID=27443 DF PROTO=UDP SPT=40626 DPT=1701 LEN=145
Jun  8 17:23:59 clyde kernel: IN= OUT=ethadsl SRC=41.134.75.12 DST=41.241.240.125 LEN=224 TOS=0x00 PREC=0x00 TTL=64 ID=27443 DF PROTO=UDP SPT=4500 DPT=4500 LEN=204


Which indicates that openl2tp immediately uses an alternate port, which could be problematic for Win7 (I'll test just now), but the fact is that the packet does get encapsulated inside ESP, specifically NATT. One more packet follows in the openl2tp -> win7 direction immediately, and then Win 7 responds with:

Code:
Jun  8 17:24:00 clyde kernel: IN=ethadsl OUT= MAC=f0:7d:68:c1:ff:d1:a4:0c:c3:62:0c:a8:08:00 SRC=41.241.240.125 DST=41.134.75.12 LEN=176 TOS=0x18 PREC=0x60 TTL=112 ID=19159 PROTO=UDP SPT=4500 DPT=4500 LEN=156
Jun  8 17:24:00 clyde kernel: IN=ethadsl OUT= MAC=f0:7d:68:c1:ff:d1:a4:0c:c3:62:0c:a8:08:00 SRC=41.241.240.125 DST=41.134.75.12 LEN=130 TOS=0x18 PREC=0x60 TTL=112 ID=19159 PROTO=UDP SPT=1701 DPT=1701 LEN=110


Which to me seems wrong, it's sending from port 1701 again, about a second after the initial packet, so it could potentially be a retransmit, or it's simply ignoring the packets from port 40626. Needless to say, this repeats for a few cycles and openl2tpd also tries to re-send it's responses a few times and then eventually Win7 reports that it's not receiving a response from the server.

The effect of adding:

Code:
tunnel profile modify profile_name=default \
        our_udp_port=1701


is a good one :). Windows 7 is now able to connect and authenticate successfully.


Top
 Profile  
 
 Post subject: Re: openl2tp + racoon interaction (Win 7 issues).
PostPosted: Mon Jun 27, 2011 7:46 pm 
Site Admin

Joined: Sun Jul 27, 2008 1:39 pm
Posts: 122
jkroon wrote:
Windows 7 is now able to connect and authenticate successfully.

Thanks for letting us know. So Windows7 doesn't honor UDP ephemeral port negotiation. That's progress, I guess. :-)


Top
 Profile  
 
 Post subject: Re: openl2tp + racoon interaction (Win 7 issues).
PostPosted: Tue Jun 28, 2011 8:24 am 

Joined: Sat Jun 04, 2011 9:18 am
Posts: 15
jchapman wrote:
jkroon wrote:
Windows 7 is now able to connect and authenticate successfully.

Thanks for letting us know. So Windows7 doesn't honor UDP ephemeral port negotiation. That's progress, I guess. :-)


Is this a negotiation? Surely then there should be a way to detect if the peer supports this negotiation right? If this is the case then openl2tp can use ephemeral negotiation for those that support it and stick to port 1701 for those that don't?


Top
 Profile  
 
 Post subject: Re: openl2tp + racoon interaction (Win 7 issues).
PostPosted: Sun Jul 17, 2011 4:02 pm 
Site Admin

Joined: Sun Jul 27, 2008 1:39 pm
Posts: 122
jkroon wrote:
jchapman wrote:
jkroon wrote:
Windows 7 is now able to connect and authenticate successfully.

Thanks for letting us know. So Windows7 doesn't honor UDP ephemeral port negotiation. That's progress, I guess. :-)


Is this a negotiation? Surely then there should be a way to detect if the peer supports this negotiation right? If this is the case then openl2tp can use ephemeral negotiation for those that support it and stick to port 1701 for those that don't?

No, it's the way UDP and TCP connections are established. When the peer receives the first L2TP packet from OpenL2TP during connection setup, it should note the source port that we chose (it's in the UDP packet header) and use that when sending future packets to OpenL2TP. Windows 7 seems to assume that all L2TP servers will always reply using port 1701.


Top
 Profile  
 
 Post subject: Re: openl2tp + racoon interaction (Win 7 issues).
PostPosted: Mon Jul 18, 2011 7:51 am 

Joined: Sat Jun 04, 2011 9:18 am
Posts: 15
jchapman wrote:
No, it's the way UDP and TCP connections are established. When the peer receives the first L2TP packet from OpenL2TP during connection setup, it should note the source port that we chose (it's in the UDP packet header) and use that when sending future packets to OpenL2TP. Windows 7 seems to assume that all L2TP servers will always reply using port 1701.


Thanks for the explanation.

Sounds like it might be a deliberate choice though. Security implications perhaps?

How would it work if both sides uses ephemeral ports? Surely at least one side needs to indicate to the other that it uses a different port? I'm used to SIP and RTP port descriptions, but don't see a way of using ephemeral ports on both sides unless there is some description being sent somewhere ...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group