On Fri, 2 Jan 2009, per...@pluto.rain.com wrote: > Ian Smith <nimnet.asn.au!smi...@agora.rdrop.com> wrote:
uucp .. how quaint :) > ... > > > tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1412 > > > inet6 fe80::2b0:d0ff:fe28:ad4f%tun0 prefixlen 64 scopeid 0x4 > > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.233.42 netmask 0xffffffff > > > Opened by PID 24635 > > > > I don't know if this is relevant or not, but I've never seen > > a point to point interface use the same IP address on both ends > > of its link before. > > I don't know either, nor whether -- and if so how -- it could keep > tun0 from responding to a ping of its own IP address. It looks like > the same issue described, for a different way of connecting to a > Cisco 3000 from FreeBSD, here: > > http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn.pdf "You don't have permission to access /~flemej/fbsd-cisco-vpn.pdf on this server." Nor http://www.cs.rpi.edu/~flemej .. so I can't consult that, but as I said, I know next to nothing about VPN configuration anyway. > If I am understanding the article correctly, the 3000 does something > unexpected in the course of setting up the P2P connection. However: > > * Since the FreeBSD config is completely different, I don't know > to what extent the w/a described there would be applicable. > > * Supposing that tun0 does need to be readdressed as > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.2.13 netmask 0xffffffff > > -- where ZZZ.ZZZ.2.13 is the address of the Cisco box on > ZZZ.ZZZ.0.0/16 -- I'm not at all clear on how a w/a should get > that internal address in the general case. (I got it by running > a traceroute from an inside machine to a working VPN-connected > Windows system, after not finding anything in the vpnc logs.) Beyond me .. I don't even know what a w/a is, but I'm pretty sure ppp is going to need a remote address, and a route to it. > * Since vpnc is supposed to have been written specifically to > connect with Cisco 3000's and similar, I'd have expected it to > somehow take care of the 3000's quirks rather than needing a > separate w/a, although I don't know enough about either tun(4) > or P2P to understand the details. Usually you can ping either end; ping <my end> is the same as ping localhost, ping <other end> is, well, that. With both the same, I'm not too surprised that ppp can't figure out which end you want to talk to? We ran ppp for 10 years on a dialup link but these days for pppoe using mpd, but the routing should come to about the same, given that here it's our default route. ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1492 inet xxx.yyy.zzz.227 --> xxx.yyy.1.33 netmask 0xffffffff Destination Gateway Flags Refs Use Netif Expire default xxx.yyy.1.33 UGS 0 24390 ng0 [..] xxx.yyy.1.33 xxx.yyy.zzz.227 UH 1 0 ng0 xxx.yyy.zzz.227/32 lo0 US 0 2 lo0 This is a 5.5 system, in case different presentation might mislead. HTH, Ian _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
