From: Loren M. L. <lo...@no...> - 2010-11-11 11:42:20
|
My set-up is using IPSec ESP to protect UDP port 1701 from Ubuntu Linux to various Windows clients with racoon. Windows 2K/XP clients can connect repeatedly successfully when either on the same subnet or with both server and client behind NAT using NAT-T with registry modification necessary for IPSec server behind NAT. Windows Vista and 7 clients can only connect once. Even worse, only the first Vista/7 client can connect when both behind the same NAT router. A specific, repeatable test case I was using is as follows. Restart racoon daemon on Linux server. Initiate L2TP VPN connection on Windows 7 (while on same subnet as Linux server.) Verify VPN is working with ping from server. First attempt is always successful. Disconnect VPN. Racoon reports ISAKMP-SA deleted. Reconnect and VPN hangs negotiating phase 2. Last message from racoon reports ISAKMP-SA established. Initiate L2TP VPN from a separate Windows XP computer also on the same subnet as the Linux server. Verify VPN connection with ping from Linux and disconnect VPN. Repeat a second time and it still successful on XP. Make sure VPN is disconnected on XP and make a third attempt at VPN on Windows 7. It still fails like the second attempt. If I delete the IPSec-SA for the Windows 7 computer with setkey or restart racoon I can make another successful connection, but while that old SA still exists I can't seem to connect. It does not seem to be a problem with XP. With Wireshark I can see the first 6 ISAKMP packets in Main Mode seem just fine and phase 1 completes normally every time, but on the seventh packet sent by Windows Vista/7 in Quick Mode, racoon fails to respond. I see no error message generated by racoon or any output related to the repeated Quick Mode packets Windows sends out with no response. With a debugger, I've narrowed it down to these lines in isakmp_main of isakmp.c: /* search isakmp phase 2 stauts record. */ iph2 = getph2bymsgid(iph1, msgid); if (iph2 == NULL) { On successful negotiations, the first Quick Mode packet will cause getph2bymsgid to return NULL whether it be 2K/XP or a successful Vista/7 negotiation. On failed Vista/7 negotiations, iph2 is not NULL from the Quick Mode packet it received and racoon then seems to ignore the packet. If I set iph2 to NULL, a successful connection will happen. Another difference I noticed is that with XP, each VPN connection attempt causes getph2bymsgid to return a different pointer to second and later Quick Mode packets, but with Vista/7, the first Quick Mode packets on a second VPN connection causes it to return the same pointer as a previous successful phase 2 negotiation. -- Loren M. Lang lo...@no... http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B |
From: Timo T. <tim...@ik...> - 2010-11-11 11:51:35
|
On 11/11/2010 01:23 PM, Loren M. Lang wrote: > My set-up is using IPSec ESP to protect UDP port 1701 from Ubuntu Linux > to various Windows clients with racoon. Windows 2K/XP clients can > connect repeatedly successfully when either on the same subnet or with > both server and client behind NAT using NAT-T with registry modification > necessary for IPSec server behind NAT. Windows Vista and 7 clients can > only connect once. Even worse, only the first Vista/7 client can > connect when both behind the same NAT router. This should be fixed in ipsec-tools 0.8 snapshots. - Timo |
From: Loren M. L. <lo...@no...> - 2010-11-11 12:46:35
Attachments:
make.errors
sa_len.patch
|
On 11/11/2010 3:51 AM, Timo Teräs wrote: > On 11/11/2010 01:23 PM, Loren M. Lang wrote: >> My set-up is using IPSec ESP to protect UDP port 1701 from Ubuntu Linux >> to various Windows clients with racoon. Windows 2K/XP clients can >> connect repeatedly successfully when either on the same subnet or with >> both server and client behind NAT using NAT-T with registry modification >> necessary for IPSec server behind NAT. Windows Vista and 7 clients can >> only connect once. Even worse, only the first Vista/7 client can >> connect when both behind the same NAT router. > > This should be fixed in ipsec-tools 0.8 snapshots. I haven't tried 0.8 yet, but I was using both 0.7 and 0.7.3 originally. I just now pulled the latest from CVS on SourceForge and the issue is still there. Also, I had some compilation issues with the CVS version. One was with code using member sa_len from a struct sockaddr which does not exists. I replaced reads from it with 32 which is larger than a sockaddr_sin6 and I commented out writes to it. The other issue was with a number of warnings about conditions always being true or fwrite return values being ignored. I fixed the warnings by dropping -Werror. I've attached my patch for sa_len as well as some of the warnings I saw during compile. I will try the 0.8 snapshot next. > > - Timo > -- Loren M. Lang lo...@no... http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B |
From: Timo T. <tim...@ik...> - 2010-11-11 13:04:08
|
On 11/11/2010 02:46 PM, Loren M. Lang wrote: > On 11/11/2010 3:51 AM, Timo Teräs wrote: >> On 11/11/2010 01:23 PM, Loren M. Lang wrote: >>> My set-up is using IPSec ESP to protect UDP port 1701 from Ubuntu Linux >>> to various Windows clients with racoon. Windows 2K/XP clients can >>> connect repeatedly successfully when either on the same subnet or with >>> both server and client behind NAT using NAT-T with registry modification >>> necessary for IPSec server behind NAT. Windows Vista and 7 clients can >>> only connect once. Even worse, only the first Vista/7 client can >>> connect when both behind the same NAT router. >> >> This should be fixed in ipsec-tools 0.8 snapshots. > > I haven't tried 0.8 yet, but I was using both 0.7 and 0.7.3 originally. > I just now pulled the latest from CVS on SourceForge and the issue is > still there. Also, I had some compilation issues with the CVS version. > One was with code using member sa_len from a struct sockaddr which does > not exists. I replaced reads from it with 32 which is larger than a > sockaddr_sin6 and I commented out writes to it. The other issue was > with a number of warnings about conditions always being true or fwrite > return values being ignored. I fixed the warnings by dropping -Werror. > I've attached my patch for sa_len as well as some of the warnings I saw > during compile. I will try the 0.8 snapshot next. The sf.net CVS is utterly old. The CVS was moved to netbsd tree and can be checked out with: cvs -da...@an...:/cvsroot co ipsec-tools - Timo |
From: Loren M. L. <lo...@al...> - 2010-11-11 13:37:19
Attachments:
lorenl.vcf
|
On 11/11/2010 4:46 AM, Loren M. Lang wrote: > On 11/11/2010 3:51 AM, Timo Teräs wrote: >> On 11/11/2010 01:23 PM, Loren M. Lang wrote: >>> My set-up is using IPSec ESP to protect UDP port 1701 from Ubuntu Linux >>> to various Windows clients with racoon. Windows 2K/XP clients can >>> connect repeatedly successfully when either on the same subnet or with >>> both server and client behind NAT using NAT-T with registry modification >>> necessary for IPSec server behind NAT. Windows Vista and 7 clients can >>> only connect once. Even worse, only the first Vista/7 client can >>> connect when both behind the same NAT router. >> >> This should be fixed in ipsec-tools 0.8 snapshots. > > I haven't tried 0.8 yet, but I was using both 0.7 and 0.7.3 originally. Just tried 0.8-alpha20101022 and I have an even more broken set-up. Shortly after the first successful connection from Vista, I get the following messages from racoon: 2010-11-11 05:03:23: INFO: 192.168.1.5[4500] used for NAT-T 2010-11-11 05:03:23: INFO: 192.168.1.5[4500] used as isakmp port (fd=5) 2010-11-11 05:03:23: INFO: 192.168.1.5[500] used for NAT-T 2010-11-11 05:03:23: INFO: 192.168.1.5[500] used as isakmp port (fd=6) Normally, I only ever see those message when first starting up racoon, never after an association. From that point on racoon is hung. When I go to disconnect, racoon ignores the Informational packets from Vista and also ignores the Main Mode messages in future connection attempts which normally work correctly. Here is the backtrace of racoon when it hits the above messages after a successful phase 2 negotiation: #0 isakmp_open (addr=0x24120a0, udp_encap=1) at isakmp.c:1730 #1 0x000000000043f594 in myaddr_open (addr=0x24120a0, udp_encap=1) at grabmyaddr.c:128 #2 0x000000000043f6d5 in myaddr_open_all_configured (addr=0x7fff74d52e60) at grabmyaddr.c:161 #3 0x000000000043fd3c in netlink_add_del_address (add=1, saddr=0x7fff74d52e60) at grabmyaddr.c:370 #4 0x00000000004400cd in netlink_process_route (h=0x7fff74d52fd0) at grabmyaddr.c:458 #5 0x0000000000440145 in netlink_process (h=0x7fff74d52fd0) at grabmyaddr.c:474 #6 0x000000000044028e in kernel_receive (ctx=0x0, fd=7) at grabmyaddr.c:512 #7 0x00000000004064ec in session () at session.c:325 #8 0x0000000000405aca in main (ac=4, av=0x7fff74d58168) at main.c:345 > I just now pulled the latest from CVS on SourceForge and the issue is > still there. Also, I had some compilation issues with the CVS version. > One was with code using member sa_len from a struct sockaddr which does > not exists. I replaced reads from it with 32 which is larger than a > sockaddr_sin6 and I commented out writes to it. The other issue was with > a number of warnings about conditions always being true or fwrite return > values being ignored. I fixed the warnings by dropping -Werror. I've > attached my patch for sa_len as well as some of the warnings I saw > during compile. I will try the 0.8 snapshot next. > >> >> - Timo >> > > > > > ------------------------------------------------------------------------------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev > > > > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel -- Loren M. Lang lo...@al... http://www.alzatex.com/ Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B |
From: Timo T. <tim...@ik...> - 2010-11-11 13:23:39
|
On 11/11/2010 03:11 PM, Loren M. Lang wrote: > On 11/11/2010 4:46 AM, Loren M. Lang wrote: >> On 11/11/2010 3:51 AM, Timo Teräs wrote: >>> On 11/11/2010 01:23 PM, Loren M. Lang wrote: >>>> My set-up is using IPSec ESP to protect UDP port 1701 from Ubuntu Linux >>>> to various Windows clients with racoon. Windows 2K/XP clients can >>>> connect repeatedly successfully when either on the same subnet or with >>>> both server and client behind NAT using NAT-T with registry >>>> modification >>>> necessary for IPSec server behind NAT. Windows Vista and 7 clients can >>>> only connect once. Even worse, only the first Vista/7 client can >>>> connect when both behind the same NAT router. >>> >>> This should be fixed in ipsec-tools 0.8 snapshots. >> >> I haven't tried 0.8 yet, but I was using both 0.7 and 0.7.3 originally. > > Just tried 0.8-alpha20101022 and I have an even more broken set-up. > Shortly after the first successful connection from Vista, I get the > following messages from racoon: > > 2010-11-11 05:03:23: INFO: 192.168.1.5[4500] used for NAT-T > 2010-11-11 05:03:23: INFO: 192.168.1.5[4500] used as isakmp port (fd=5) > 2010-11-11 05:03:23: INFO: 192.168.1.5[500] used for NAT-T > 2010-11-11 05:03:23: INFO: 192.168.1.5[500] used as isakmp port (fd=6) > > Normally, I only ever see those message when first starting up racoon, > never after an association. From that point on racoon is hung. When I > go to disconnect, racoon ignores the Informational packets from Vista > and also ignores the Main Mode messages in future connection attempts > which normally work correctly. Here is the backtrace of racoon when it > hits the above messages after a successful phase 2 negotiation: That's probably racoon binding to listen ipsec packets on the new IP assigned via l2tp. It was actually previously a (Linux kernel) bug that it failed to bind on them; it's worked around now by using different notifications. Though I'm not sure why racoon would hang on that. Does racoon hang on a loop somewhere and use 100% cpu? Or it's just not responding to any packets? - Timo |
From: Timo T. <tim...@ik...> - 2010-11-11 14:14:35
|
On 11/11/2010 04:08 PM, Loren M. Lang wrote: >> That's probably racoon binding to listen ipsec packets on the new IP >> assigned via l2tp. It was actually previously a (Linux kernel) bug that >> it failed to bind on them; it's worked around now by using different >> notifications. >> >> Though I'm not sure why racoon would hang on that. Does racoon hang on >> a >> loop somewhere and use 100% cpu? Or it's just not responding to any >> packets? > > No, it just ignores packets. I am running a two year old kernel so it > might be the bug. One difference between alpha20090903 and all other > releases is that racoon spits out listening messages for every IPv4/6 > address on the server and after a connection, it spits out one more > for the IPv6 link-local of the L2TP connection. Later racoon releases > spit out the sames messages mentioned above during startup and after > connection. Yes, that's expected. Racoon was always supposed to work like that. To bind() to all new addresses as they appear. So that behaviour is correct. However, starting to ignore some packets is not right. Could you perhaps provide strace or more detailed debug log? Thanks, Timo |
From: Loren M. L. <lo...@al...> - 2010-11-11 13:32:20
Attachments:
lorenl.vcf
|
On 11/11/2010 5:11 AM, Loren M. Lang wrote: > On 11/11/2010 4:46 AM, Loren M. Lang wrote: >> On 11/11/2010 3:51 AM, Timo Teräs wrote: >>> On 11/11/2010 01:23 PM, Loren M. Lang wrote: >>>> My set-up is using IPSec ESP to protect UDP port 1701 from Ubuntu Linux >>>> to various Windows clients with racoon. Windows 2K/XP clients can >>>> connect repeatedly successfully when either on the same subnet or with >>>> both server and client behind NAT using NAT-T with registry >>>> modification >>>> necessary for IPSec server behind NAT. Windows Vista and 7 clients can >>>> only connect once. Even worse, only the first Vista/7 client can >>>> connect when both behind the same NAT router. >>> >>> This should be fixed in ipsec-tools 0.8 snapshots. >> >> I haven't tried 0.8 yet, but I was using both 0.7 and 0.7.3 originally. > > Just tried 0.8-alpha20101022 and I have an even more broken set-up. The lastest CVS version also exhibits this same behavior and there was one warning during compile where I had to disable -Werror: racoonctl.c: In function ‘handle_recv’: racoonctl.c:1465: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result > Shortly after the first successful connection from Vista, I get the > following messages from racoon: > > 2010-11-11 05:03:23: INFO: 192.168.1.5[4500] used for NAT-T > 2010-11-11 05:03:23: INFO: 192.168.1.5[4500] used as isakmp port (fd=5) > 2010-11-11 05:03:23: INFO: 192.168.1.5[500] used for NAT-T > 2010-11-11 05:03:23: INFO: 192.168.1.5[500] used as isakmp port (fd=6) > > Normally, I only ever see those message when first starting up racoon, > never after an association. From that point on racoon is hung. When I go > to disconnect, racoon ignores the Informational packets from Vista and > also ignores the Main Mode messages in future connection attempts which > normally work correctly. Here is the backtrace of racoon when it hits > the above messages after a successful phase 2 negotiation: > > #0 isakmp_open (addr=0x24120a0, udp_encap=1) at isakmp.c:1730 > #1 0x000000000043f594 in myaddr_open (addr=0x24120a0, udp_encap=1) at > grabmyaddr.c:128 > #2 0x000000000043f6d5 in myaddr_open_all_configured > (addr=0x7fff74d52e60) at grabmyaddr.c:161 > #3 0x000000000043fd3c in netlink_add_del_address (add=1, > saddr=0x7fff74d52e60) at grabmyaddr.c:370 > #4 0x00000000004400cd in netlink_process_route (h=0x7fff74d52fd0) at > grabmyaddr.c:458 > #5 0x0000000000440145 in netlink_process (h=0x7fff74d52fd0) at > grabmyaddr.c:474 > #6 0x000000000044028e in kernel_receive (ctx=0x0, fd=7) at grabmyaddr.c:512 > #7 0x00000000004064ec in session () at session.c:325 > #8 0x0000000000405aca in main (ac=4, av=0x7fff74d58168) at main.c:345 > > >> I just now pulled the latest from CVS on SourceForge and the issue is >> still there. Also, I had some compilation issues with the CVS version. >> One was with code using member sa_len from a struct sockaddr which does >> not exists. I replaced reads from it with 32 which is larger than a >> sockaddr_sin6 and I commented out writes to it. The other issue was with >> a number of warnings about conditions always being true or fwrite return >> values being ignored. I fixed the warnings by dropping -Werror. I've >> attached my patch for sa_len as well as some of the warnings I saw >> during compile. I will try the 0.8 snapshot next. >> >>> >>> - Timo >>> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Centralized Desktop Delivery: Dell and VMware Reference Architecture >> Simplifying enterprise desktop deployment and management using >> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end >> client virtualization framework. Read more! >> http://p.sf.net/sfu/dell-eql-dev2dev >> >> >> >> _______________________________________________ >> Ipsec-tools-devel mailing list >> Ips...@li... >> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > > -- Loren M. Lang lo...@al... http://www.alzatex.com/ Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B |
From: Loren M. L. <lo...@al...> - 2010-11-11 13:37:38
Attachments:
lorenl.vcf
|
On 11/11/2010 5:23 AM, Loren M. Lang wrote: > On 11/11/2010 5:11 AM, Loren M. Lang wrote: >> On 11/11/2010 4:46 AM, Loren M. Lang wrote: >>> On 11/11/2010 3:51 AM, Timo Teräs wrote: >>>> On 11/11/2010 01:23 PM, Loren M. Lang wrote: >>>>> My set-up is using IPSec ESP to protect UDP port 1701 from Ubuntu >>>>> Linux >>>>> to various Windows clients with racoon. Windows 2K/XP clients can >>>>> connect repeatedly successfully when either on the same subnet or with >>>>> both server and client behind NAT using NAT-T with registry >>>>> modification >>>>> necessary for IPSec server behind NAT. Windows Vista and 7 clients can >>>>> only connect once. Even worse, only the first Vista/7 client can >>>>> connect when both behind the same NAT router. >>>> >>>> This should be fixed in ipsec-tools 0.8 snapshots. >>> >>> I haven't tried 0.8 yet, but I was using both 0.7 and 0.7.3 originally. >> >> Just tried 0.8-alpha20101022 and I have an even more broken set-up. > > The lastest CVS version also exhibits this same behavior and there was > one warning during compile where I had to disable -Werror: > > racoonctl.c: In function ‘handle_recv’: > racoonctl.c:1465: warning: ignoring return value of ‘fwrite’, declared > with attribute warn_unused_result I just tried 0.8-alpha20090903 and it works! However, when I tried to specify the configuration file with -f I got a seg fault. Apparently lcconf is NULL inside parse(). I worked around this by hard coding the right configuration file into it. > >> Shortly after the first successful connection from Vista, I get the >> following messages from racoon: >> >> 2010-11-11 05:03:23: INFO: 192.168.1.5[4500] used for NAT-T >> 2010-11-11 05:03:23: INFO: 192.168.1.5[4500] used as isakmp port (fd=5) >> 2010-11-11 05:03:23: INFO: 192.168.1.5[500] used for NAT-T >> 2010-11-11 05:03:23: INFO: 192.168.1.5[500] used as isakmp port (fd=6) >> >> Normally, I only ever see those message when first starting up racoon, >> never after an association. From that point on racoon is hung. When I go >> to disconnect, racoon ignores the Informational packets from Vista and >> also ignores the Main Mode messages in future connection attempts which >> normally work correctly. Here is the backtrace of racoon when it hits >> the above messages after a successful phase 2 negotiation: >> >> #0 isakmp_open (addr=0x24120a0, udp_encap=1) at isakmp.c:1730 >> #1 0x000000000043f594 in myaddr_open (addr=0x24120a0, udp_encap=1) at >> grabmyaddr.c:128 >> #2 0x000000000043f6d5 in myaddr_open_all_configured >> (addr=0x7fff74d52e60) at grabmyaddr.c:161 >> #3 0x000000000043fd3c in netlink_add_del_address (add=1, >> saddr=0x7fff74d52e60) at grabmyaddr.c:370 >> #4 0x00000000004400cd in netlink_process_route (h=0x7fff74d52fd0) at >> grabmyaddr.c:458 >> #5 0x0000000000440145 in netlink_process (h=0x7fff74d52fd0) at >> grabmyaddr.c:474 >> #6 0x000000000044028e in kernel_receive (ctx=0x0, fd=7) at >> grabmyaddr.c:512 >> #7 0x00000000004064ec in session () at session.c:325 >> #8 0x0000000000405aca in main (ac=4, av=0x7fff74d58168) at main.c:345 >> >> >>> I just now pulled the latest from CVS on SourceForge and the issue is >>> still there. Also, I had some compilation issues with the CVS version. >>> One was with code using member sa_len from a struct sockaddr which does >>> not exists. I replaced reads from it with 32 which is larger than a >>> sockaddr_sin6 and I commented out writes to it. The other issue was with >>> a number of warnings about conditions always being true or fwrite return >>> values being ignored. I fixed the warnings by dropping -Werror. I've >>> attached my patch for sa_len as well as some of the warnings I saw >>> during compile. I will try the 0.8 snapshot next. >>> >>>> >>>> - Timo >>>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> Centralized Desktop Delivery: Dell and VMware Reference Architecture >>> Simplifying enterprise desktop deployment and management using >>> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end >>> client virtualization framework. Read more! >>> http://p.sf.net/sfu/dell-eql-dev2dev >>> >>> >>> >>> _______________________________________________ >>> Ipsec-tools-devel mailing list >>> Ips...@li... >>> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel >> >> > > -- Loren M. Lang lo...@al... http://www.alzatex.com/ Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B |
From: Loren M. L. <lo...@no...> - 2010-11-12 10:09:50
|
On 11/12/2010 1:53 AM, Timo Teräs wrote: > On 11/12/2010 11:28 AM, Loren M. Lang wrote: >>> Sounds like your L2TP scripts mess up the original ppp0 IP-address. >>> >>> What does e.g. "ip address" say when racoon stops reacting to messages? >>> It sounds like someone is deconfigured your ppp interface >>> unintentionally. >> >> My ppp0 interface works fine after the connection. I can ping the >> client's IP over the VPN and connect to it with smbclient. I expect it >> will eventually fail once the associations expire, but the only issue >> initially is that racoon no longer sees any packets. > > Yes, according to the rtmon dump, the kernel says that your ppp0 address > is no longer available. Well, it says "local route to 192.168.1.5 dev > ppp0" deleted. This causes racoon to unbind from 192.168.1.5 and that's > also why it disappears from the netstat list. At the end of that test I did disconnect the VPN so ppp0 was indeed deleted, but only when it should have been. It was working up until I disconnected. Now 0.8-alpha20090123 seems to do things differently than all other versions of racoon I've tested. Instead of doing a wildcard bind, it binds to every possible interface including localhost. When ppp0 comes up, it binds to the IPv6 link-local address and unbinds only from that on disconnect. Can later versions of racoon be configured to do this as well? Another detail of my setup I just realized is probably the root of the problem. I use IPv4 address 192.168.1.5 as the local end of all ppp tunnels and allocate an IPv4 address from 192.168.1.50-59 for the remote end. 192.168.1.5 is also the IPv4 address of that server on the local ethernet interface eth1. I use proxy arp so that VPN clients appear on the local network to keep my network simple. This is especially important for Windows clients so I can avoid enabling the VPN as a default gateway slowing down their Internet access. Windows assumes it's a class C and adds the appropriate route. If I gave VPN clients their own subnet, I'd need the VPN to be the default gateway. I assume Racoon before 0.8 did not try to dynamically attach to network interfaces and so has not been a problem with my setup. Should I try and bind racoon only to 192.168.1.5 or is there some other workaround? > >> 287: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc >> pfifo_fast state UNKNOWN qlen 3 >> link/ppp >> inet 192.168.1.5 peer 192.168.1.50/32 scope global ppp0 >> inet6 fe80::4/10 scope link >> valid_lft forever preferred_lft forever > > But the address is still here. Which is kinda strange. > > Perhaps try "watch -n1 ip route show table local" to see how it changes > during the various situations. You could also do "watch -n1 ip addr show > dev ppp0" to see if the link details change throughout the happening. > > According to logs, someone is really messing up ppp0 IP address back and > forth when you do things. > > - Timo > -- Loren M. Lang lo...@no... http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B |
From: Timo T. <tim...@ik...> - 2010-11-12 10:29:52
|
On 11/12/2010 12:09 PM, Loren M. Lang wrote: > I assume Racoon before 0.8 did not try to dynamically attach to network > interfaces and so has not been a problem with my setup. Should I try > and bind racoon only to 192.168.1.5 or is there some other workaround? Yes, it should have. But due to various other bugs, it probably did not work as expected. You can bind to specific IP by adding something like: listen { isakmp 192.168.1.5[500]; isakmp_natt 192.168.1.5[4500]; } Cheers, Timo |
From: Loren M. L. <lo...@no...> - 2010-11-12 11:05:59
|
On 11/12/2010 2:29 AM, Timo Teräs wrote: > On 11/12/2010 12:09 PM, Loren M. Lang wrote: >> I assume Racoon before 0.8 did not try to dynamically attach to network >> interfaces and so has not been a problem with my setup. Should I try >> and bind racoon only to 192.168.1.5 or is there some other workaround? > > Yes, it should have. But due to various other bugs, it probably did not > work as expected. > > You can bind to specific IP by adding something like: > listen { > isakmp 192.168.1.5[500]; > isakmp_natt 192.168.1.5[4500]; > } These lines have been in my racoon config since day one when I set up this L2TP config: listen { isakmp 192.168.1.5; isakmp_natt 192.168.1.5 [4500]; } > > Cheers, > Timo > -- Loren M. Lang lo...@no... http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B |
From: Loren M. L. <lo...@al...> - 2010-11-12 11:15:15
Attachments:
lorenl.vcf
|
On 11/12/2010 3:05 AM, Loren M. Lang wrote: > On 11/12/2010 2:29 AM, Timo Teräs wrote: >> On 11/12/2010 12:09 PM, Loren M. Lang wrote: >>> I assume Racoon before 0.8 did not try to dynamically attach to network >>> interfaces and so has not been a problem with my setup. Should I try >>> and bind racoon only to 192.168.1.5 or is there some other workaround? >> >> Yes, it should have. But due to various other bugs, it probably did not >> work as expected. >> >> You can bind to specific IP by adding something like: >> listen { >> isakmp 192.168.1.5[500]; >> isakmp_natt 192.168.1.5[4500]; >> } > > These lines have been in my racoon config since day one when I set up > this L2TP config: > > listen > { > isakmp 192.168.1.5; > isakmp_natt 192.168.1.5 [4500]; > } Removing those lines causes later versions of racoon to behave closer to 0.8-alpha20090123 where they bind to many interfaces. When I connect the VPN I see a second binding for 192.168.1.5 show up, but when I disconnect the VPN both go away. I guess I was saved by a couple bugs in 2009 which cause it to just work in my setup. It bound once to that IP and never disconnected. Is there no way to do a wildcard binding with UDP like is typically done with TCP services and avoid dynamically creating/destroying bindings? > >> >> Cheers, >> Timo >> > > -- Loren M. Lang lo...@al... http://www.alzatex.com/ Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B |
From: Loren M. L. <lo...@al...> - 2010-11-12 11:23:31
Attachments:
lorenl.vcf
|
On 11/12/2010 3:14 AM, Loren M. Lang wrote: > On 11/12/2010 3:05 AM, Loren M. Lang wrote: >> On 11/12/2010 2:29 AM, Timo Teräs wrote: >>> On 11/12/2010 12:09 PM, Loren M. Lang wrote: >>>> I assume Racoon before 0.8 did not try to dynamically attach to network >>>> interfaces and so has not been a problem with my setup. Should I try >>>> and bind racoon only to 192.168.1.5 or is there some other workaround? >>> >>> Yes, it should have. But due to various other bugs, it probably did not >>> work as expected. >>> >>> You can bind to specific IP by adding something like: >>> listen { >>> isakmp 192.168.1.5[500]; >>> isakmp_natt 192.168.1.5[4500]; >>> } I spoke too soon. Adding strict_address to the listen clause had the right effect. >> >> These lines have been in my racoon config since day one when I set up >> this L2TP config: >> >> listen >> { >> isakmp 192.168.1.5; >> isakmp_natt 192.168.1.5 [4500]; >> } > > Removing those lines causes later versions of racoon to behave closer to > 0.8-alpha20090123 where they bind to many interfaces. When I connect the > VPN I see a second binding for 192.168.1.5 show up, but when I > disconnect the VPN both go away. I guess I was saved by a couple bugs in > 2009 which cause it to just work in my setup. It bound once to that IP > and never disconnected. Is there no way to do a wildcard binding with > UDP like is typically done with TCP services and avoid dynamically > creating/destroying bindings? > >> >>> >>> Cheers, >>> Timo >>> >> >> > > -- Loren M. Lang lo...@al... http://www.alzatex.com/ Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B |
From: Timo T. <tim...@ik...> - 2010-12-03 09:49:50
|
On 11/12/2010 12:34 PM, Timo Teräs wrote: > On 11/12/2010 12:12 PM, Loren M. Lang wrote: >>> How is the device connected to Internet? Using ethx? Does the ethX have >>> same IP address assigned to it as ppp0? Are those bridged? proxy-arp? >> >> I realized this was coming in the last email. I am not using bridging >> but I am using proxy arp. eth1 is the LAN interface which is also where >> VPN clients connect and the IP Address is shared with the local end of >> ppp interfaces. >> >>> Sounds, like ppp0 and ethX has same IP, and kernel a bug that it's >>> giving a false deleted notification. >> >> I'll be installing a new server in a couple weeks with much updated >> software. Hopefully this will fix it. > > Actually, it won't. Looks like the kernel keeps duplicate local routes > which I did not anticipate. Technically, this same bug should have > happened earlier, but did not for some reason (probably due to another > bug I fixed). > > I'll figure out a way to fix this properly. For now, you'll need to bind > racoon to a specific IP. I have just committed a fix for this issue to ipsec-tools CVS master. Address is not unbound until it actually gets deleted. This fix should fix the issue you experienced. - Timo |