Re: ospfd and L2VPN routes
On Wed, 5 Mar 2014 10:55:51 -0800 "Paul B. Henson" wrote: >> From: YASUOKA Masahiko >> Sent: Wednesday, March 05, 2014 3:20 AM >> >> % ospfctl show fib | grep 128 >> *56 10.128.120.0/24 127.0.0.1 >> *56 10.128.120.213/3210.0.0.1 > > Interesting, not only does it show a /24 route, it looks like it has it > marked as valid. Is this with pppx or tun? IIRC, when I tested tun ospfd > found a /24 route, but still didn't propagate it. That was with tun. >> Even if tun(4) is used, packets are processed in-kernel. > > Ah, I had thought pipex was just for pppx, but now I see in the man page it > says "pipex is used with tun(4) and pppx". What's the difference between tun > and pppx in the context of npppd then? Is there any particular reason to use > one versus the other for an L2TP VPN? pppx(4) creates a interface for each PPP session. tun(4) doesn't create any interface and uses only one interface for all PPP sessions. Generally pppx's way is thought to be natural and tun's way is tricky. Old system had had some problems if it has a lot of interfaces. tun's way had been used to avoid those problems. So I think pppx should be used. --yasuoka
Re: ospfd and L2VPN routes
On Wed, 5 Mar 2014 10:50:10 -0800 "Paul B. Henson" wrote: >> From: YASUOKA Masahiko >> Sent: Wednesday, March 05, 2014 1:48 AM >> >> "framed-ip-netmask" in npppd-user to set the netmask of the route to >> the PPP link. But it is not to set the client netmask (on iPhone). >> >> AFAIK to set the client netmask, DHCP inform can be used. > > Hmm, I thought the VPN client picked up its IP address from IPCP? Of cource it does. But netmask is not supported by IPCP. > How would you get DHCP involved? Some clients (AFAIK Windows, MacOS and iPhone) are waiting a DHCP inform on their PPP link. If we can send the DHCP inform, the clients will receive that. (Though I have not tried that with our dhcpd yet.) --yasuoka
Re: ospfd and L2VPN routes
> From: YASUOKA Masahiko > Sent: Wednesday, March 05, 2014 3:20 AM > > % ospfctl show fib | grep 128 > *56 10.128.120.0/24 127.0.0.1 > *56 10.128.120.213/3210.0.0.1 Interesting, not only does it show a /24 route, it looks like it has it marked as valid. Is this with pppx or tun? IIRC, when I tested tun ospfd found a /24 route, but still didn't propagate it. > And do you know why the ospfd doesn't use "the whole /24"? No, not a clue :(. I tried posting an inquiry to the tech list in the hope someone familiar with the guts of osfpd might comment, but no responses so far. > Even if tun(4) is used, packets are processed in-kernel. Ah, I had thought pipex was just for pppx, but now I see in the man page it says "pipex is used with tun(4) and pppx". What's the difference between tun and pppx in the context of npppd then? Is there any particular reason to use one versus the other for an L2TP VPN? Thanks much.
Re: ospfd and L2VPN routes
> From: YASUOKA Masahiko > Sent: Wednesday, March 05, 2014 1:48 AM > > "framed-ip-netmask" in npppd-user to set the netmask of the route to > the PPP link. But it is not to set the client netmask (on iPhone). > > AFAIK to set the client netmask, DHCP inform can be used. Hmm, I thought the VPN client picked up its IP address from IPCP? How would you get DHCP involved? Also, it's not really the netmask of the client's IP address, but the mask for the route from the client to the VPN'd network that needs to be tweaked.
Re: ospfd and L2VPN routes
On Sat, 1 Mar 2014 18:42:11 -0800 "Paul B. Henson" wrote: > On Sat, Mar 01, 2014 at 07:41:10PM +0900, YASUOKA Masahiko wrote: >> I could repeat the problem. ospfd seems not to be able to use routes >> set by npppd. The problem seems to be come from pppx(4)'s behavior of >> its link state. >> >> Using tun(4) instead of pppx(4) avoid the problem. > > If I switch npppd to use tun, after startup (before any clients even > connect) ospfd shows three routes: > > # ospfctl show fib | grep 120 > *56 10.128.120.0/24 127.0.0.1 > 4 10.128.120.1/32 10.128.120.1 > *56 10.128.120.1/32 127.0.0.1 > > Kind of odd ones though, routing the whole /24 to localhost? After a > client connects, it adds another /32 to it: > > # ospfctl show fib | grep 120 > *56 10.128.120.0/24 127.0.0.1 > 4 10.128.120.1/32 10.128.120.1 > *56 10.128.120.1/32 127.0.0.1 > 56 10.128.120.12/32 10.128.120.1 > > And after the client disconnects, it goes away: > > # ospfctl show fib | grep 120 > *56 10.128.120.0/24 127.0.0.1 > 4 10.128.120.1/32 10.128.120.1 > *56 10.128.120.1/32 127.0.0.1 > > However, it's still not advertised by ospfd to other routers, so the > client still can't communicate with the network beyond the openbsd > router terminating the vpn connection. I see the problem of /32 route. But it doesn't occur on my environment (OpenBSD 5.5-beta/amd64).. % ospfctl show fib | grep 128 *56 10.128.120.0/24 127.0.0.1 *56 10.128.120.213/3210.0.0.1 % And do you know why the ospfd doesn't use "the whole /24"? > So while tun seems to avoid the pppx problem of dangling routes, it > still doesn't solve the issue of ospfd not advertising them . > > pppx is more efficient than tun, right? It keeps packets in the kernel > rather than bouncing them through userspace? Even if tun(4) is used, packets are processed in-kernel. --yasuoka
Re: ospfd and L2VPN routes
On Sat, 1 Mar 2014 18:23:08 -0800 "Paul B. Henson" wrote: > On Sat, Mar 01, 2014 at 01:48:06PM +0900, YASUOKA Masahiko wrote: >> > on the other side? Right now it looks like the client is setting a >> > route to 10.0.0.0/8 across the tunnel, that should actually be >> > 10.128.0.0/16, would setting the netmask in npppd-users fix that remote >> > route? Can I set the netmask but still let the client get a dynamic IP? >> >> My answer was wrong. Assigning statically or netmask to the client is >> not related the ospf problem, I'm sorry. > > No worries, I appreciate the help :). I tried setting the netmask in > npppd-users, that didn't change the /8 route the iPhone client set. From > a little investigation, it doesn't look like there's any way to set the > client netmask for the l2tp vpn route? The client just does whatever it > wants it seems, whether to just assume a class based route (/8 in the > case of my 10.128 address) or some seem to just assume a /24 8-/. You'd > think defining the client netmask would be part of the protocol, but > unless I'm missing something, I guess it's not. "framed-ip-netmask" in npppd-user to set the netmask of the route to the PPP link. But it is not to set the client netmask (on iPhone). AFAIK to set the client netmask, DHCP inform can be used. Also I found some bugs around "framed-ip-netmask". I will fix them soon. --yasuoka
Re: ospfd and L2VPN routes
On Sat, Mar 01, 2014 at 11:55:28AM +, Andy Lemin wrote: > Hi, it's not a good idea to distribute /32 routes around your routing > domain as it will make convergence times longer and adds unnecessary > load to the other routers. OSPF and other routing daemons like summary > routes. I'm guessing you've assigned a 'unique' /24 network for the > VPN clients which isn't used anywhere else in your organisation so the > best thing to do is to create a single static route on the OBSD box > for the whole /24 VPN range and distribute that using OSPF. That way > other routers will learn about the OBSD box which provides access to > the clients etc. leave the /32 routes on the OBSD box.. Well, from a theoretical ideal perspective, it would be better for only routes to valid vpn clients to exist on the network, so any packet to an IP not in use by an active client would get null routed at its source, rather than sent all the way to the openbsd box to get dropped. On the other hand, from a pragmatic implementation perspective, you're right, you don't really want 200 /32 routes floating around when they could be covered by a single /24. However, in this case, there probably won't be more than a handful of clients at any given time, so it's not really a choice between a single /24 and 254 /32's, but more like between a single /24 and half a dozen /32's, so I'm leaning towards theoretical ideal at this point ;). Besides, even if I do end up hacking it with a static /24, for self edification purposes I still want to understand why it's not working and what it would take to make it work :). Thanks...
Re: ospfd and L2VPN routes
On Sat, Mar 01, 2014 at 07:41:10PM +0900, YASUOKA Masahiko wrote: > I could repeat the problem. ospfd seems not to be able to use routes > set by npppd. The problem seems to be come from pppx(4)'s behavior of > its link state. > > Using tun(4) instead of pppx(4) avoid the problem. If I switch npppd to use tun, after startup (before any clients even connect) ospfd shows three routes: # ospfctl show fib | grep 120 *56 10.128.120.0/24 127.0.0.1 4 10.128.120.1/32 10.128.120.1 *56 10.128.120.1/32 127.0.0.1 Kind of odd ones though, routing the whole /24 to localhost? After a client connects, it adds another /32 to it: # ospfctl show fib | grep 120 *56 10.128.120.0/24 127.0.0.1 4 10.128.120.1/32 10.128.120.1 *56 10.128.120.1/32 127.0.0.1 56 10.128.120.12/32 10.128.120.1 And after the client disconnects, it goes away: # ospfctl show fib | grep 120 *56 10.128.120.0/24 127.0.0.1 4 10.128.120.1/32 10.128.120.1 *56 10.128.120.1/32 127.0.0.1 However, it's still not advertised by ospfd to other routers, so the client still can't communicate with the network beyond the openbsd router terminating the vpn connection. So while tun seems to avoid the pppx problem of dangling routes, it still doesn't solve the issue of ospfd not advertising them . pppx is more efficient than tun, right? It keeps packets in the kernel rather than bouncing them through userspace? No ospfd experts that would like to chime in :)? The vpn /32 routes don't seem to be marked as either valid or connected... Thanks...
Re: ospfd and L2VPN routes
On Sat, Mar 01, 2014 at 01:48:06PM +0900, YASUOKA Masahiko wrote: > > on the other side? Right now it looks like the client is setting a > > route to 10.0.0.0/8 across the tunnel, that should actually be > > 10.128.0.0/16, would setting the netmask in npppd-users fix that remote > > route? Can I set the netmask but still let the client get a dynamic IP? > > My answer was wrong. Assigning statically or netmask to the client is > not related the ospf problem, I'm sorry. No worries, I appreciate the help :). I tried setting the netmask in npppd-users, that didn't change the /8 route the iPhone client set. From a little investigation, it doesn't look like there's any way to set the client netmask for the l2tp vpn route? The client just does whatever it wants it seems, whether to just assume a class based route (/8 in the case of my 10.128 address) or some seem to just assume a /24 8-/. You'd think defining the client netmask would be part of the protocol, but unless I'm missing something, I guess it's not. > npppd set a /32 route for a VPN client and delete it when the link > down. > > > Isn't each instance of pppx for the VPN a /32 route to the remote > > IP? > > You had 16 /32 routes. Don't you mean you had 32 VPN clients > actually, right? I only had one or two test clients connected at a time. But it looks like ospfd picks up the route when a VPN client connects, but then doesn't drop it when it disconnects, so the routes pile up. After reloading the fib with no vpn clients, there are no /32 routes: # ospfctl fib reload reload request sent. # ospfctl show fib | grep 120 I connect a client and a route shows up (but isn't advertised to the other ospf connected routers): # ospfctl show fib | grep 120 4 10.128.120.109/3210.128.120.1 I disconnect the client, it's still there: # ospfctl show fib | grep 120 4 10.128.120.109/3210.128.120.1 I reconnect the client, it receives a different IP, and there are now two routes: # ospfctl show fib | grep 120 4 10.128.120.109/3210.128.120.1 4 10.128.120.155/3210.128.120.1 Disconnect, still two routes: # ospfctl show fib | grep 120 4 10.128.120.109/3210.128.120.1 4 10.128.120.155/3210.128.120.1 Definitely something not quite right with ospfd and npppd l2tp vpns. Thanks...
Re: ospfd and L2VPN routes
Hi, it's not a good idea to distribute /32 routes around your routing domain as it will make convergence times longer and adds unnecessary load to the other routers. OSPF and other routing daemons like summary routes. I'm guessing you've assigned a 'unique' /24 network for the VPN clients which isn't used anywhere else in your organisation so the best thing to do is to create a single static route on the OBSD box for the whole /24 VPN range and distribute that using OSPF. That way other routers will learn about the OBSD box which provides access to the clients etc. leave the /32 routes on the OBSD box.. Hope this helps. Cheers, Andy. Sent from my iPhone > On 1 Mar 2014, at 10:41, YASUOKA Masahiko wrote: > > On Fri, 28 Feb 2014 12:41:16 -0800 > "Paul B. Henson" wrote: >> I'm currently setting up an L2TP VPN with npppd. I've got the VPN piece >> working, and can send packets between the client and the openbsd box >> running the vpn. However, I'm currently using ospfd for routing between >> the rest of the network and the openbsd box, and it doesn't seem to be >> pushing routes for the IP addresses in use by the clients. > > I could repeat the problem. ospfd seems not to be able to use routes > set by npppd. The problem seems to be come from pppx(4)'s behavior of > its link state. > > Using tun(4) instead of pppx(4) avoid the problem. > > --yasuoka
Re: ospfd and L2VPN routes
On Fri, 28 Feb 2014 12:41:16 -0800 "Paul B. Henson" wrote: > I'm currently setting up an L2TP VPN with npppd. I've got the VPN piece > working, and can send packets between the client and the openbsd box > running the vpn. However, I'm currently using ospfd for routing between > the rest of the network and the openbsd box, and it doesn't seem to be > pushing routes for the IP addresses in use by the clients. I could repeat the problem. ospfd seems not to be able to use routes set by npppd. The problem seems to be come from pppx(4)'s behavior of its link state. Using tun(4) instead of pppx(4) avoid the problem. --yasuoka
Re: ospfd and L2VPN routes
On Fri, 28 Feb 2014 19:42:26 -0800 "Paul B. Henson" wrote: > On Sat, Mar 01, 2014 at 11:23:01AM +0900, YASUOKA Masahiko wrote: >> I'm not sure whether it works. Can you try it by static route? > > A static route on the network on the other side of the openbsd box? I'm > sure that would work; when I try to ping a box out in the network from > the vpn client, I can see the outbound pings traversing the link from > the openbsd box to the router on the other side: > > 19:24:43.669307 10.128.120.163 > 10.128.130.1: icmp: echo request > 19:24:44.646823 10.128.120.163 > 10.128.130.1: icmp: echo request > 19:24:45.644309 10.128.120.163 > 10.128.130.1: icmp: echo request > 19:24:46.666878 10.128.120.163 > 10.128.130.1: icmp: echo request > > The return packets are getting dropped due to the lack of a route, so if > I had a static route on the other side it would work, but I'd rather not > use static routes, ideally I can make ospfd dynamically advertise routes > as necessary. Sorry I thought you were trying to add additional routes though the PPP client. Now I understand what you are trying. >> Also, if there is a network behind the vpn, you can assign a static ip >> address and netmask instead of assigning /32 dynamic address. See >> npppd-users(5) and use framed-ip-address and framed-ip-netmask. > > I'd prefer not to assign a static IP per user, I like the concept of > just having a dynamic pool and users just get whatever address out of > it. I'm not sure how the netmask would work for a point-to-point link? > How could it be anything but a /32? Or would the netmask be for the route > on the other side? Right now it looks like the client is setting a > route to 10.0.0.0/8 across the tunnel, that should actually be > 10.128.0.0/16, would setting the netmask in npppd-users fix that remote > route? Can I set the netmask but still let the client get a dynamic IP? My answer was wrong. Assigning statically or netmask to the client is not related the ospf problem, I'm sorry. >> many /32 routes show something wrong. > > Why? npppd set a /32 route for a VPN client and delete it when the link down. > Isn't each instance of pppx for the VPN a /32 route to the remote > IP? You had 16 /32 routes. Don't you mean you had 32 VPN clients actually, right? Sorry, I'm not good at ospfd, so I could not anwer other questions soon. --yasuoka
Re: ospfd and L2VPN routes
On Sat, Mar 01, 2014 at 11:23:01AM +0900, YASUOKA Masahiko wrote: > I'm not sure whether it works. Can you try it by static route? A static route on the network on the other side of the openbsd box? I'm sure that would work; when I try to ping a box out in the network from the vpn client, I can see the outbound pings traversing the link from the openbsd box to the router on the other side: 19:24:43.669307 10.128.120.163 > 10.128.130.1: icmp: echo request 19:24:44.646823 10.128.120.163 > 10.128.130.1: icmp: echo request 19:24:45.644309 10.128.120.163 > 10.128.130.1: icmp: echo request 19:24:46.666878 10.128.120.163 > 10.128.130.1: icmp: echo request The return packets are getting dropped due to the lack of a route, so if I had a static route on the other side it would work, but I'd rather not use static routes, ideally I can make ospfd dynamically advertise routes as necessary. > Also, if there is a network behind the vpn, you can assign a static ip > address and netmask instead of assigning /32 dynamic address. See > npppd-users(5) and use framed-ip-address and framed-ip-netmask. I'd prefer not to assign a static IP per user, I like the concept of just having a dynamic pool and users just get whatever address out of it. I'm not sure how the netmask would work for a point-to-point link? How could it be anything but a /32? Or would the netmask be for the route on the other side? Right now it looks like the client is setting a route to 10.0.0.0/8 across the tunnel, that should actually be 10.128.0.0/16, would setting the netmask in npppd-users fix that remote route? Can I set the netmask but still let the client get a dynamic IP? > npppd setup the routes for configured pool addresses to reserve them. > I think this is the reason why ospfd seems to know something. If I scrub everything clean, there are no routes to 10.128.120 in ospfd: # ospfctl show fib | grep 120 Now, if I connect a client, route monitor shows: RTM_IFANNOUNCE: iface arrival/departure: len 26, if# 18, name pppx0, what: arrival got message of size 96 on Fri Feb 28 19:33:20 2014 RTM_NEWADDR: address being added to iface: len 96, metric 0, flags: sockaddrs: 255.255.255.255 pppx0 10.128.120.1 10.128.120.230 got message of size 120 on Fri Feb 28 19:33:20 2014 RTM_ADD: Add Route: len 120, priority 4, table 0, pid: 0, seq 0, errno 0 flags: use:0 mtu:0expire:0 locks: inits: sockaddrs: 10.128.120.230 10.128.120.1 and ospf lists it: # ospfctl show fib | grep 120 4 10.128.120.230/3210.128.120.1 > many /32 routes show something wrong. Why? Isn't each instance of pppx for the VPN a /32 route to the remote IP? It seems like everything is working as it should, other than ospf *not* advertising the /32 route it finds out about? If ospfd pushed that route out, the VPN client would work correctly. Hmm, also, route monitor shows the route being removed when the client disconnects: RTM_DELETE: Delete Route: len 120, priority 0, table 0, pid: 0, seq 0, errno 0 flags: use:0 mtu:0expire:0 locks: inits: sockaddrs: 10.128.120.230 10.128.120.1 got message of size 26 on Fri Feb 28 19:35:21 2014 RTM_IFANNOUNCE: iface arrival/departure: len 26, if# 18, name pppx0, what: departure but ospfd doesn't lose it: # ospfctl show fib | grep 120 4 10.128.120.230/3210.128.120.1 until I explicitly reload the fib: # ospfctl fib reload reload request sent. # ospfctl show fib | grep 120 That doesn't seem right either. Thanks...
Re: ospfd and L2VPN routes
On Fri, 28 Feb 2014 12:41:16 -0800 "Paul B. Henson" wrote: > I'm currently setting up an L2TP VPN with npppd. I've got the VPN piece > working, and can send packets between the client and the openbsd box > running the vpn. However, I'm currently using ospfd for routing between > the rest of the network and the openbsd box, and it doesn't seem to be > pushing routes for the IP addresses in use by the clients. I'm not sure whether it works. Can you try it by static route? Also, if there is a network behind the vpn, you can assign a static ip address and netmask instead of assigning /32 dynamic address. See npppd-users(5) and use framed-ip-address and framed-ip-netmask. > So, after a couple VPN clients connect, there are pppx interfaces: > > pppx0: flags=8051 mtu 1360 > description: henson > priority: 0 > groups: pppx > inet 10.128.120.1 --> 10.128.120.82 netmask 0x > > pppx1: flags=8051 mtu 1360 > description: henson > priority: 0 > groups: pppx > inet 10.128.120.1 --> 10.128.120.121 netmask 0x > > and the local routing tables know how to get to them: > > DestinationGatewayFlags Refs Use Mtu Prio Iface > 10.128.120.82 10.128.120.1 UH 0 10 - 4 pppx0 > 10.128.120.121 10.128.120.1 UH 0 63 - 4 pppx1 > > ospfd seems to know *something* about the /24 I've allocated to the VPN: npppd setup the routes for configured pool addresses to reserve them. I think this is the reason why ospfd seems to know something. But > flags: * = valid, O = OSPF, C = Connected, S = Static > Flags Prio Destination Nexthop > *C4 10.128.110.0/24 link#7 > 4 10.128.120.43/32 10.128.120.1 > 4 10.128.120.45/32 10.128.120.1 > 4 10.128.120.82/32 10.128.120.1 many /32 routes show something wrong. --yasuoka
ospfd and L2VPN routes
I'm currently setting up an L2TP VPN with npppd. I've got the VPN piece working, and can send packets between the client and the openbsd box running the vpn. However, I'm currently using ospfd for routing between the rest of the network and the openbsd box, and it doesn't seem to be pushing routes for the IP addresses in use by the clients. So, after a couple VPN clients connect, there are pppx interfaces: pppx0: flags=8051 mtu 1360 description: henson priority: 0 groups: pppx inet 10.128.120.1 --> 10.128.120.82 netmask 0x pppx1: flags=8051 mtu 1360 description: henson priority: 0 groups: pppx inet 10.128.120.1 --> 10.128.120.121 netmask 0x and the local routing tables know how to get to them: DestinationGatewayFlags Refs Use Mtu Prio Iface 10.128.120.82 10.128.120.1 UH 0 10 - 4 pppx0 10.128.120.121 10.128.120.1 UH 0 63 - 4 pppx1 ospfd seems to know *something* about the /24 I've allocated to the VPN: flags: * = valid, O = OSPF, C = Connected, S = Static Flags Prio Destination Nexthop *C4 10.128.110.0/24 link#7 4 10.128.120.43/32 10.128.120.1 4 10.128.120.45/32 10.128.120.1 4 10.128.120.82/32 10.128.120.1 4 10.128.120.107/3210.128.120.1 4 10.128.120.121/3210.128.120.1 4 10.128.120.160/3210.128.120.1 4 10.128.120.163/3210.128.120.1 4 10.128.120.165/3210.128.120.1 4 10.128.120.208/3210.128.120.1 4 10.128.120.212/3210.128.120.1 4 10.128.120.214/3210.128.120.1 4 10.128.120.219/3210.128.120.1 4 10.128.120.223/3210.128.120.1 4 10.128.120.233/3210.128.120.1 4 10.128.120.246/3210.128.120.1 4 10.128.120.248/3210.128.120.1 *O 32 10.128.130.0/24 10.128.0.14 But it doesn't have the active ones marked as valid, and it's not pushing them, so there's no traffic flow between the vpn client and the network. I currently have ospfd set to: redistribute default redistribute connected While I am pushing a default route, I also have lower priority null routes set on the other network equipment: ip route 10.0.0.0 255.0.0.0 Null0 254 ip route 172.16.0.0 255.240.0.0 Null0 254 ip route 192.168.0.0 255.255.0.0 Null0 254 So they will blackhole any address space not valid on the network. Am I missing some configuration that will make ospfd push out routes to the client VPN addresses? Thanks...
