G
Guest
I have access to the internet via cable modem, and I use a VPN connection
into work. Certain work networks are accessible only if accessed via the
VPN. If I tried to access them across the internet, the accesses would be
blocked by a firewall at work. Other test networks simply aren't meant to be
routed across the internet.
After establishing the VPN connection, I added two permanent routes, using
"route -p add" in an administrator command prompt.
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
155.53.0.0 255.255.0.0 172.31.253.150 1
10.0.0.0 255.0.0.0 172.31.253.150 1
===========================================================================
Everything works fine at this point.
C:\Windows\system32>tracert -d 155.53.12.61
Tracing route to 155.53.12.61 over a maximum of 30 hops
1 29 ms 26 ms 26 ms 172.31.253.11
2 27 ms 30 ms 28 ms 155.53.2.254
3 28 ms 30 ms 26 ms 155.53.12.61
Trace complete.
C:\Windows\system32>
My problem occurs when the vpn is disconnected and reconnected, whether this
occurs manually or due to a reboot or whatever. In that case, the persistent
routes continue, however they no longer route through the vpn. For example,
routing table and failing tracert follows (this is after disconnecting and
reconnecting vpn):
C:\Windows\system32>route print -4
===========================================================================
Interface List
20 ........................... VPN Connection
8 ...00 13 02 09 bc e3 ...... Intel(R) PRO/Wireless 3945ABG Network Connect
7 ...00 14 22 ef 4d 5f ...... Broadcom 440x 10/100 Integrated Controller
1 ........................... Software Loopback Interface 1
10 ...02 00 54 55 4e 01 ...... Teredo Tunneling Pseudo-Interface
13 ...00 00 00 00 00 00 00 e0 isatap.rr.net
21 ...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
14 ...00 00 00 00 00 00 00 e0 6TO4 Adapter
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.103 20
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
155.53.1.12 255.255.255.255 192.168.2.1 192.168.2.103 21
172.31.0.0 255.255.0.0 172.31.253.11 172.31.253.89 21
172.31.253.89 255.255.255.255 On-link 172.31.253.89 276
192.168.2.0 255.255.255.0 On-link 192.168.2.103 276
192.168.2.103 255.255.255.255 On-link 192.168.2.103 276
192.168.2.255 255.255.255.255 On-link 192.168.2.103 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.2.103 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.2.103 276
255.255.255.255 255.255.255.255 On-link 172.31.253.89 276
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
155.53.0.0 255.255.0.0 172.31.253.150 1
10.0.0.0 255.0.0.0 172.31.253.150 1
===========================================================================
C:\Windows\system32>tracert -d 155.53.12.61
Tracing route to 155.53.12.61 over a maximum of 30 hops
1 3 ms <1 ms <1 ms 192.168.2.1
2 10 ms 6 ms 9 ms 24.30.144.1
3 7 ms 7 ms 9 ms 24.25.193.65
4 7 ms 12 ms 9 ms 24.25.196.142
5 8 ms 8 ms 8 ms 24.25.196.129
6 9 ms 9 ms 12 ms 4.79.36.9
7 13 ms 11 ms 8 ms 4.68.113.93
8 11 ms 13 ms 13 ms 64.159.1.126
9 12 ms 12 ms 12 ms 4.68.102.174
10 14 ms 11 ms 15 ms 4.68.110.114
11 26 ms 24 ms 26 ms 151.164.95.84
12 31 ms 30 ms 31 ms 69.108.221.138
13 30 ms 28 ms 30 ms 155.53.1.254
14 * * * Request timed out.
If I re-enter the exact same persistent routes (using route -p change, with
the same information), the routing table remains the same, however everything
starts working again.
So it seems that vista is assigning an output interface along with the
route, although it doesn't appear to be displayed in the routing table. Is
there a way to force vista to re-evaluate the persistent routes when a new
vpn connection is made, and thereby possibly reassign a new output interface
to the route? Ideally this would be automatic, since I'd rather not run a
script to reset the routes everytime the vpn connection is made.
I realize I could simply have a default route through the vpn, but that
would slow down most other internet accesses. So I've specifically disabled
the default route through the vpn.
into work. Certain work networks are accessible only if accessed via the
VPN. If I tried to access them across the internet, the accesses would be
blocked by a firewall at work. Other test networks simply aren't meant to be
routed across the internet.
After establishing the VPN connection, I added two permanent routes, using
"route -p add" in an administrator command prompt.
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
155.53.0.0 255.255.0.0 172.31.253.150 1
10.0.0.0 255.0.0.0 172.31.253.150 1
===========================================================================
Everything works fine at this point.
C:\Windows\system32>tracert -d 155.53.12.61
Tracing route to 155.53.12.61 over a maximum of 30 hops
1 29 ms 26 ms 26 ms 172.31.253.11
2 27 ms 30 ms 28 ms 155.53.2.254
3 28 ms 30 ms 26 ms 155.53.12.61
Trace complete.
C:\Windows\system32>
My problem occurs when the vpn is disconnected and reconnected, whether this
occurs manually or due to a reboot or whatever. In that case, the persistent
routes continue, however they no longer route through the vpn. For example,
routing table and failing tracert follows (this is after disconnecting and
reconnecting vpn):
C:\Windows\system32>route print -4
===========================================================================
Interface List
20 ........................... VPN Connection
8 ...00 13 02 09 bc e3 ...... Intel(R) PRO/Wireless 3945ABG Network Connect
7 ...00 14 22 ef 4d 5f ...... Broadcom 440x 10/100 Integrated Controller
1 ........................... Software Loopback Interface 1
10 ...02 00 54 55 4e 01 ...... Teredo Tunneling Pseudo-Interface
13 ...00 00 00 00 00 00 00 e0 isatap.rr.net
21 ...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
14 ...00 00 00 00 00 00 00 e0 6TO4 Adapter
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.103 20
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
155.53.1.12 255.255.255.255 192.168.2.1 192.168.2.103 21
172.31.0.0 255.255.0.0 172.31.253.11 172.31.253.89 21
172.31.253.89 255.255.255.255 On-link 172.31.253.89 276
192.168.2.0 255.255.255.0 On-link 192.168.2.103 276
192.168.2.103 255.255.255.255 On-link 192.168.2.103 276
192.168.2.255 255.255.255.255 On-link 192.168.2.103 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.2.103 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.2.103 276
255.255.255.255 255.255.255.255 On-link 172.31.253.89 276
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
155.53.0.0 255.255.0.0 172.31.253.150 1
10.0.0.0 255.0.0.0 172.31.253.150 1
===========================================================================
C:\Windows\system32>tracert -d 155.53.12.61
Tracing route to 155.53.12.61 over a maximum of 30 hops
1 3 ms <1 ms <1 ms 192.168.2.1
2 10 ms 6 ms 9 ms 24.30.144.1
3 7 ms 7 ms 9 ms 24.25.193.65
4 7 ms 12 ms 9 ms 24.25.196.142
5 8 ms 8 ms 8 ms 24.25.196.129
6 9 ms 9 ms 12 ms 4.79.36.9
7 13 ms 11 ms 8 ms 4.68.113.93
8 11 ms 13 ms 13 ms 64.159.1.126
9 12 ms 12 ms 12 ms 4.68.102.174
10 14 ms 11 ms 15 ms 4.68.110.114
11 26 ms 24 ms 26 ms 151.164.95.84
12 31 ms 30 ms 31 ms 69.108.221.138
13 30 ms 28 ms 30 ms 155.53.1.254
14 * * * Request timed out.
If I re-enter the exact same persistent routes (using route -p change, with
the same information), the routing table remains the same, however everything
starts working again.
So it seems that vista is assigning an output interface along with the
route, although it doesn't appear to be displayed in the routing table. Is
there a way to force vista to re-evaluate the persistent routes when a new
vpn connection is made, and thereby possibly reassign a new output interface
to the route? Ideally this would be automatic, since I'd rather not run a
script to reset the routes everytime the vpn connection is made.
I realize I could simply have a default route through the vpn, but that
would slow down most other internet accesses. So I've specifically disabled
the default route through the vpn.