|
|
On Tuesday 03 August 2004 16:44, Fabio Antonio Esquivel Chacón wrote:
> On Thu, 29 Jul 2004 18:41:30 -0500, James Yonan <jim@xxxxxxxxx> wrote:
> > On Thursday 29 July 2004 18:17, Fabio Antonio Esquivel Chacón wrote:
> >> Note the line for 10.2.0.0? It's going through the public IP!
> >
> > Fabio,
> >
> > Yes this looks like an OpenVPN bug. The problem is that the TAP
> > interface at the time that the routes are being added has no IP address,
> > so this is confusing OpenVPN's new route add function which uses the IP
> > helper API rather than route.exe.
> >
> > I will put together a fix shortly.
> >
> > James
>
> I just downloaded and installed OpenVPN 2 beta 10 and retried my configs...
> No luck yet: It still routes my Intranet traffic through the public ISP,
> going nowhere...
>
> Peer Connection Initiated with <public server IP>:5000
> DEBUG: test_routes: 1/1 succeeded len=1 ret=1 a=0 u/d=up
> route ADD 10.3.1.1 MASK 255.255.255.255 10.3.2.1 METRIC 1
> Route addition via IPAPI succeeded
>
> Note that this time I added that explicit route to just one host (10.3.1.1
> is my CISCO gateway for the Intranet) and although it seems OK, it actually
> gets lost... PING or traceroute just get lost going through the public
> Interface (196.40.42.9, dynamically assigned by my dial-up ISP):
>
> SYSTEM ROUTING TABLE
> 0.0.0.0 0.0.0.0 196.40.42.9 p=0 i=131076 t=3 pr=3 a=516 h=0 m=1/-1/-1/-1/-1
> 10.3.1.1 255.255.255.255 10.3.2.1 p=0 i=327683 t=4 pr=3 a=0 h=0
The route appears to have been added correctly by beta10. Note the above
line. It refers to interface #327683 which you will see below is the correct
interface index for the TAP interface. The beta9 bug which we saw earlier
got the interface index wrong in certain cases.
> m=1/-1/-1/-1/-1 10.3.2.0 255.255.255.0 10.3.2.2 p=0 i=327683 t=3 pr=2 a=6
> h=0 m=1/-1/-1/-1/-1 10.3.2.2 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=6
> h=0 m=1/-1/-1/-1/-1 10.255.255.255 255.255.255.255 10.3.2.2 p=0 i=327683
> t=3 pr=2 a=6 h=0 m=1/-1/-1/-1/-1 127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3
> pr=2 a=24730 h=0 m=1/-1/-1/-1/-1 196.40.40.1 255.255.255.255 196.40.42.9
> p=0 i=131076 t=4 pr=3 a=516 h=0 m=1/-1/-1/-1/-1 196.40.42.9 255.255.255.255
> 127.0.0.1 p=0 i=1 t=3 pr=2 a=516 h=0 m=50/-1/-1/-1/-1 196.40.42.255
> 255.255.255.255 196.40.42.9 p=0 i=131076 t=3 pr=2 a=516 h=0
> m=50/-1/-1/-1/-1 224.0.0.0 240.0.0.0 10.3.2.2 p=0 i=327683 t=3 pr=2 a=6 h=0
> m=1/-1/-1/-1/-1 224.0.0.0 240.0.0.0 196.40.42.9 p=0 i=131076 t=3 pr=3 a=516
> h=0 m=1/-1/-1/-1/-1 255.255.255.255 255.255.255.255 10.3.2.2 p=0 i=327683
> t=3 pr=2 a=14 h=0 m=1/-1/-1/-1/-1 255.255.255.255 255.255.255.255
> 196.40.42.9 p=0 i=131076 t=3 pr=2 a=516 h=0 m=1/-1/-1/-1/-1 SYSTEM ADAPTER
> LIST
> TAP-Win32 Adapter V8
> Index = 327683
The above line refers to the adapter index of the TAP adapter. All routes on
Windows must specify an adapter index.
> GUID = {384CF9B3-56AF-40DB-A51F-4C23E44ACE29}
> IP = 10.3.2.2/255.255.255.0
This looks right. The bug in beta9 would cause the routes to be attempted to
be added before the IP address was set on the adapter. The above line shows
that the IP address has been set correctly at the time the route was added.
> MAC = 00:ff:38:4c:f9:b3
> GATEWAY =
> DHCP SERV = 10.3.2.0
> DHCP LEASE OBTAINED = Tue Aug 03 15:28:06 2004
> DHCP LEASE EXPIRES = Wed Aug 03 15:28:06 2005
> WAN (PPP/SLIP) Interface
> Index = 131076
> GUID = {08292016-581C-4BEA-9F54-C54CA0F5F975}
> IP = 196.40.42.9/255.255.255.255
> MAC = 00:53:45:00:00:00
> GATEWAY = 196.40.42.9/0.0.0.0
>
> What else could I do to diagnose this? How can I force the TAP driver to
> route through it my Intranet routes?
The TAP driver doesn't do any routing.
The route statement you've given is telling Windows to route packets having a
destination address of 10.3.1.1 to the TAP adapter.
If you're still having problems, then it's probably an issue with your config
files.
James
____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|