On Saturday, 9 June 2018 01:20:18 BST Hilco Wijbenga wrote:
> On Fri, Jun 8, 2018 at 4:34 PM Mick <michaelkintz...@gmail.com> wrote:
> > On Friday, 8 June 2018 23:21:52 BST Grant Taylor wrote:
> > > On 06/08/2018 03:31 PM, Hilco Wijbenga wrote:
> > > > Sigh, I take it back. That causes the internal sites to no longer
> > > > work.
> > > 
> > > Okay.
> > > 
> > > So you're on the proper track.
> > > 
> > > I'm guessing the work network isn't a simple single prefix.  Or at least
> > > the VPN client doesn't route enough through the VPN.
> > > 
> > > Check your routing table with the VPN connected.  Is enough being routed
> > > through?  Do you need to add additional prefixes?
> > > 
> > > If DNS is working properly for internal resources, make sure that what
> > > they resolve to is routed through the VPN.
> > 
> > I don't know what networkmanager offers in terms of VPN settings, but as
> > Grant says you need to set split routing.  As it currently is, everything
> > is sent out through the tunnel and your work's router is not set up to
> > route out to the Internet your VPN connection.
> > 
> > If networkmanager does not get you what you want, you can do this with 'ip
> > route'.  Delete the default route, then set again the default route via
> > the
> > your local gateway:
> > 
> > # ip route del default via 192.168.1.254 dev wlan0
> > # ip route add default via 192.168.1.254 dev wlan0
> > 
> > then create an additional route for the remote subnet if it's not there:
> > 
> > # ip route add 10.10.20.0/24 via 172.16.1.1 dev wlan0
> > 
> > Where 10.10.20.0/24 is your work's subnet and 172.16.1.1 is the local VPN
> > IP address for your PC.  Something along these lines ought to work.
> 
> I fooled around with "ip" but while removing ("del default") was easy,
> "add default" did not seem to do anything.
> 
> Let me give some more information, perhaps that will help.
> 
> Setup without VPN
> $ ip route
> default via 192.168.151.1 dev eth0 proto static metric 100
> 127.0.0.0/8 via 127.0.0.1 dev lo
> 192.168.151.0/24 dev eth0 proto kernel scope link src 192.168.151.103 metric
> 100
> 
> (192.168.151.1 is my own gateway, an old computer functioning as router)
> 
> 
> Setup with VPN (Gateway: vpn.company.com; Other DNS Servers:
> dns1,dns2; Search Domains:
> r1.i.company.com,r2.i.company.com,r3.i.company.com,r4.i.company.com,r5.i.com
> pany.com,r6.i.company.com,r7.i.company.com,r8.i.company.com,i.company.com,co
> nfig) $ ip route
> default via 192.168.151.1 dev eth0 proto static metric 100
> $SOME_COMPANY_IP_1 dev tun0 proto kernel scope link src
> $SOME_COMPANY_IP_1 metric 50

You can try adding a route against this link so the first IP is a subnet for 
your connection to the remote LAN.  If for example $SOME_COMPANY_IP_1 is 
192.168.10.5 you can try:

# ip route add 192.168.10.0/24 via 192.168.10.5 dev tun0


> 127.0.0.0/8 via 127.0.0.1 dev lo
> 192.168.151.0/24 dev eth0 proto kernel scope link src 192.168.151.103 metric
> 100 192.168.151.1 dev eth0 proto static scope link metric 100
> $VPN_GATEWAY via 192.168.151.1 dev eth0 proto static metric 100
> 
> (where $SOME_COMPANY_IP is the IP of some internal server, and

I think you'll find $SOME_COMPANY_IP_1 is the remote LAN IP address offered by 
the company's VPN gateway to your PC, so that you can connect to the company's 
LAN subnet.


> $VPN_GATEWAY is the IP of vpn.company.com).
> ==> This does _not_ allow me to access (e.g.) *.i.company.com but
> everything else works fine.
> 
> 
> Same setup but without "Use only for resources on this connection":
> $ ip route
> default dev tun0 proto static scope link metric 50
> default via 192.168.151.1 dev eth0 proto static metric 100
> $SOME_COMPANY_IP_2 dev tun0 proto kernel scope link src
> $SOME_COMPANY_IP_2 metric 50
> 127.0.0.0/8 via 127.0.0.1 dev lo
> 192.168.151.0/24 dev eth0 proto kernel scope link src 192.168.151.103 metric
> 100 192.168.151.1 dev eth0 proto static scope link metric 100
> $VPN_GATEWAY via 192.168.151.1 dev eth0 proto static metric 100
> 
> (note that $SOME_COMPANY_IP_1 and $SOME_COMPANY_IP_2 differ only in
> the last digit; this seems to go up by one every time I connect to
> VPN, so probably irrelevant)

The company's VPN gateway will increment new VPN connections giving them the 
next IP address allocated to the VPN pool.  When you disconnect your client, 
the VPN gateway ought to tear down the connection and release the IP address, 
but this does not happen instantaneously in most implementations in case the 
disconnection is temporary.  So this is to be expected.


> ==> This allows me to access *.i.company.com but breaks everything else.

It would do so, because everything is sent out the default device tun0 and 
your company's firewall will not route connections from your VPN allocated LAN 
address to the Internet.  Just curious, does it allow you to connect to the 
Internet AND your company's LAN, if while under this set up you run:

# ip route del default via 192.168.151.1 dev eth0
# ip route add default via 192.168.151.1 dev eth0

This would add the default via 192.168.151.1 above your default dev tun0.

> What would be the "correct" output for "ip route"?

It depends on the platform, VPN client and its configuration.  I don't have a 
VPN configured at present to compare.

-- 
Regards,
Mick

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to