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...
