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: <NETMASK,IFP,IFA,BRD> 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:<UP,HOST> use: 0 mtu: 0 expire: 0 locks: inits: sockaddrs: <DST,GATEWAY> 10.128.120.230 10.128.120.1 and ospf lists it: # ospfctl show fib | grep 120 4 10.128.120.230/32 10.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:<UP,HOST,DONE> use: 0 mtu: 0 expire: 0 locks: inits: sockaddrs: <DST,GATEWAY> 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/32 10.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...