Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Tue, Jun 19, 2018 at 1:02 PM, Grant Taylor wrote: > On 06/19/2018 05:57 AM, Mick wrote: >> >> Actually, I don't know if there is a way to set up multiple nameservers >> for corresponding name resolution in/out of the tunnel, without using a >> domain- specific override as you would with dnsmasq and without leaking DNS >> queries to the ISP if you are meant to be querying the tunnel's nameservers. > > > My go to solution would be a local DNS server that decides where different > queries go. That's what NM does. It uses dnsmasq. (Maybe not by default but that's how I've got it running.) >> Yes, those VPN implementations that set up separate routing policy tables >> help to keep main and 'VPN' rules separate, which is neat and easy to >> maintain. only contains the route from the local VPN subnet to the remote >> LAN subnet. > > > Yep. > >> Quite. The user (or his VPN client via some NM plugin) is meant to add in >> this networkmanager IPv4/Route tab the remote LAN subnet(s) and enable "Use >> only for resources on this connection" in order to set up a split tunnel. >> Then tun0 will only be used to tunnel connections to these subnets. All >> other connections to the Internet or local LAN will go outside the tunnel, >> using the default local gateway. > > > *nod* > >> Given Hilco's results I'm surmising an empty table in the NM translates as >> 0.0.0.0/0 and all connections end up being routed via the VPN stack, but I >> could be wrong because I don't know what he may have entered in this table. > > Agreed. Originally, I had nothing in there. Adding the one route (see my email on June 7th) makes it working ... mostly. >> Yes, but leaving the routes table empty ... it seems to tunnel everything >> through it ... I don't know without trying it out myself or getting more >> info on the settings. > > > Ya. This is unexpected behavior to me. I also don't have a convenient way > to reproduce it. > >> I expect you can set up a subnet here and from this the NM will configure >> the route accordingly to make it go through the VPN stack. > > > That is the expected behavior. > > IMHO the lack of additional routes mean that nothing other than the VPN link > itself should be routed through the VPN. > >> Is this something I can manipulate via resolv.conf on the local PC >> (without a local resolver) to make sure DNS searches meant for the VPN stack >> are tunneled to the remote nameservers not leaked outside it? > > > I don't know of a good way to do this without a local DNS server. > >> PS. Thanks for your write up on network namespaces. I'll look into this >> in more depth when I get a minute, because I would like to contain/isolate >> desktop applications I inherently mistrust - e.g. Skype. > > > You're welcome. I'm glad to hear people benefiting from it. Feel free to > reach out if you have any questions. Thanks for discussing this. At minimum it's quite interesting. :-)
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/19/2018 05:57 AM, Mick wrote: Actually, I don't know if there is a way to set up multiple nameservers for corresponding name resolution in/out of the tunnel, without using a domain- specific override as you would with dnsmasq and without leaking DNS queries to the ISP if you are meant to be querying the tunnel's nameservers. My go to solution would be a local DNS server that decides where different queries go. Yes, those VPN implementations that set up separate routing policy tables help to keep main and 'VPN' rules separate, which is neat and easy to maintain. only contains the route from the local VPN subnet to the remote LAN subnet. Yep. Quite. The user (or his VPN client via some NM plugin) is meant to add in this networkmanager IPv4/Route tab the remote LAN subnet(s) and enable "Use only for resources on this connection" in order to set up a split tunnel. Then tun0 will only be used to tunnel connections to these subnets. All other connections to the Internet or local LAN will go outside the tunnel, using the default local gateway. *nod* Given Hilco's results I'm surmising an empty table in the NM translates as 0.0.0.0/0 and all connections end up being routed via the VPN stack, but I could be wrong because I don't know what he may have entered in this table. Agreed. Yes, but leaving the routes table empty ... it seems to tunnel everything through it ... I don't know without trying it out myself or getting more info on the settings. Ya. This is unexpected behavior to me. I also don't have a convenient way to reproduce it. I expect you can set up a subnet here and from this the NM will configure the route accordingly to make it go through the VPN stack. That is the expected behavior. IMHO the lack of additional routes mean that nothing other than the VPN link itself should be routed through the VPN. Is this something I can manipulate via resolv.conf on the local PC (without a local resolver) to make sure DNS searches meant for the VPN stack are tunneled to the remote nameservers not leaked outside it? I don't know of a good way to do this without a local DNS server. PS. Thanks for your write up on network namespaces. I'll look into this in more depth when I get a minute, because I would like to contain/isolate desktop applications I inherently mistrust - e.g. Skype. You're welcome. I'm glad to hear people benefiting from it. Feel free to reach out if you have any questions. -- Grant. . . . unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Monday, 18 June 2018 15:37:00 BST Grant Taylor wrote: > On 06/18/2018 04:30 AM, Mick wrote: > > The above does not offer him a route into the company's LAN and he cannot > > connect to the servers *.i.company.com. > > Small nuance that routes don't deal with names and that names must be > translated to IPs. But that does require making sure there are routes > to the proper name server to do said translation. Yes, domain name resolution for remote hosts within the remote LAN space has to happen before routing to an IP address takes place. If these remote machines are not publicly accessible, Hilco's PC will need to have configured his company's nameservers. Some (all?) VPN clients use scripts to achieve this once a connection with the remote peer has taken place. Many distros use dnsmasq to set up separate nameservers for split tunnels. With Gentoo (without dnsmasq) I have found the remote peer's nameservers are written in resolv.conf by the VPN client Up script, but only for full tunnels. I've noticed with strongswan when setting up split tunnels it errors out as it tries to set a nameserver for the tunnel side and ends up with the local default gateway nameserver only. Of course remote peer private name space resolutions fail, because the local nameserver does not know anything about them. Actually, I don't know if there is a way to set up multiple nameservers for corresponding name resolution in/out of the tunnel, without using a domain- specific override as you would with dnsmasq and without leaking DNS queries to the ISP if you are meant to be querying the tunnel's nameservers. > > When the above setting is left disabled, then Hilco can access the company > > domain, but not the Internet - a full tunnel. His route table now shows > > tun0 as being the default NIC: > > It seems like you're using "full tunnel" to mean that everything is > routed through the tunnel. Save for the VPN tunnel traffic itself. > > I figured that's what you meant, but I wanted to ask and be sure. > > > My understanding of a "split tunnel" or "split horizon" as you call it > > involves two routes: > > > > 1. Route for connections via the VPN tunnel: > > > > One route is used to direct datagrams from a local subnet or a virtual > > VPN IP allocated by the remote VPN gateway, e.g. $SOME_COMPANY_IP_1, > > via the VPN tunnel (tun0) to the remote company's LAN. > > > > 2. Route for all other connections, outside the VPN tunnel: > > > > A second route is typically the default route of the PC for all other > > connections and it is used to route datagrams outside the VPN tunnel. > > Agreed. Though there may be more routes for additional subnets routed > through the VPN. This is what I think Hilco is wanting to do. > > > Some VPN clients add a new routing policy rule table (e.g. strongswan), > > but others (e.g. racoon) add routes for the VPN tunnel in the main > > routing policy rule table. > > I was not aware that any VPNs used alternate routing tables and rules to > use them. But that does make sense. Programmatically, that may be > simpler to maintain and clean up after the VPN is shut down too. I.e. > assume that anything in the routing table is for the VPN and safe to > remove, along with the single predictable rule referencing said table. Yes, those VPN implementations that set up separate routing policy tables help to keep main and 'VPN' rules separate, which is neat and easy to maintain. >From memory Strongswan in particular sets up a rule table with ID 220, which only contains the route from the local VPN subnet to the remote LAN subnet. > > In contrast, a "full tunnel" directs all outgoing datagrams from any > > local subnet via the VPN. > > I agree at a high level. The nuanced nitpicks don't matter at this point. > > > I appreciate what I describe above is inverse to what the setting "Use > > only for resources on this connection" is meant to do, but I merely go > > by the route tables Hilco has provided. > > My not-yet-awake brain doesn't see the inverse issue that you're > referring to. But I'm used to dealing with VPNs, so maybe something is > instinctive for me. > > > Hmm ... prompted by your question in this post I had to give it a second > > thought, and I've come up with this hypothesis: > > > > IF no specific subnet routes are defined on the NM routes tab AND the "Use > > only for resources on this connection" is selected, then it may be that > > networkmanager translates no subnet entry to mean 0.0.0.0/0 - ALL routes > > will be tunneled via the VPN, leaving nothing for the default route. > > Using a (translated or not) route of "0.0.0.0/0" seems antithetical to > "Use only for resources on this connection". Quite. The user (or his VPN client via some NM plugin) is meant to add in this networkmanager IPv4/Route tab the remote LAN subnet(s) and enable "Use only for resources on this connection" in order to set up a split tunnel. Then tun0 will only be
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/18/2018 04:30 AM, Mick wrote: Hi Grant, Hi Mick, I am not overly familiar with networkmanager and the OP has not shared any screenshots or tab-by-tab NM settings, but had a look on a Gnome desktop and when hovering over the "Use only for resources on this connection" setting in the IPv4 Routes tab, it offers this tip: "If enabled, this connection will never be used as the default network connection." This tip alone hints that enabling it ought to create a split tunnel, for any subnets defined within this tab to be routed via the VPN, but everything else to be routed via the default route. Agreed. When Hilco enabled it he obtained this route table: … The above does not offer him a route into the company's LAN and he cannot connect to the servers *.i.company.com. Small nuance that routes don't deal with names and that names must be translated to IPs. But that does require making sure there are routes to the proper name server to do said translation. When the above setting is left disabled, then Hilco can access the company domain, but not the Internet - a full tunnel. His route table now shows tun0 as being the default NIC: It seems like you're using "full tunnel" to mean that everything is routed through the tunnel. Save for the VPN tunnel traffic itself. I figured that's what you meant, but I wanted to ask and be sure. My understanding of a "split tunnel" or "split horizon" as you call it involves two routes: 1. Route for connections via the VPN tunnel: One route is used to direct datagrams from a local subnet or a virtual VPN IP allocated by the remote VPN gateway, e.g. $SOME_COMPANY_IP_1, via the VPN tunnel (tun0) to the remote company's LAN. 2. Route for all other connections, outside the VPN tunnel: A second route is typically the default route of the PC for all other connections and it is used to route datagrams outside the VPN tunnel. Agreed. Though there may be more routes for additional subnets routed through the VPN. This is what I think Hilco is wanting to do. Some VPN clients add a new routing policy rule table (e.g. strongswan), but others (e.g. racoon) add routes for the VPN tunnel in the main routing policy rule table. I was not aware that any VPNs used alternate routing tables and rules to use them. But that does make sense. Programmatically, that may be simpler to maintain and clean up after the VPN is shut down too. I.e. assume that anything in the routing table is for the VPN and safe to remove, along with the single predictable rule referencing said table. In contrast, a "full tunnel" directs all outgoing datagrams from any local subnet via the VPN. I agree at a high level. The nuanced nitpicks don't matter at this point. I appreciate what I describe above is inverse to what the setting "Use only for resources on this connection" is meant to do, but I merely go by the route tables Hilco has provided. My not-yet-awake brain doesn't see the inverse issue that you're referring to. But I'm used to dealing with VPNs, so maybe something is instinctive for me. Hmm ... prompted by your question in this post I had to give it a second thought, and I've come up with this hypothesis: IF no specific subnet routes are defined on the NM routes tab AND the "Use only for resources on this connection" is selected, then it may be that networkmanager translates no subnet entry to mean 0.0.0.0/0 - ALL routes will be tunneled via the VPN, leaving nothing for the default route. Using a (translated or not) route of "0.0.0.0/0" seems antithetical to "Use only for resources on this connection". Without more information on NM's specific settings I'm not sure why routing is screwed up like this. :-) I don't think it is screwed up. Enabling "Use only for resources on this connection" doesn't change the default route. Disabling "Use only for resources on this connection" does change the default route. It does look like NetworkManager has the concept of additional routes that should be routed through the VPN. However when hovering over the box that I think you enter them in, "Editing IPv4 routes for VPN connection $NAME", I get a tool tip balloon that says "IP addresses identify your computer on the network. Click the Add button to add an IP address.". Which makes one think the dialog box is for enter IP addresses. However I suspect that's an artifact of how the dialog box is constructed and re-using the same code as for entering IPs. The Address, Netmask, Gateway, and Metric fields do sound like routes. Though I question the wisdom of a static gateway in this case verses the tunnel device. Nevertheless, adding a route manually for the remote LAN subnet as per my previous post should deliver a 'split tunnel/horizon', assuming the DNS nameservers are also somehow sorted out. I suspect that the client needs to be directed to use the DNS servers on the corporate LAN and ensure that their
Re: [gentoo-user] Enable "regular" network traffic when using VPN
Hi Grant, On Monday, 18 June 2018 03:59:32 BST Grant Taylor wrote: > On 06/17/2018 03:05 PM, Mick wrote: > > TBH I wouldn't select "Use only for resources on this connection", > > I thought "Use only for resources on this connection" would enable (what > I know as) "split horizon", which is what I thought the OP wanted to do. > In other words route company traffic through the VPN and route > everything not to the company via the ISP. I am not overly familiar with networkmanager and the OP has not shared any screenshots or tab-by-tab NM settings, but had a look on a Gnome desktop and when hovering over the "Use only for resources on this connection" setting in the IPv4 Routes tab, it offers this tip: "If enabled, this connection will never be used as the default network connection." This tip alone hints that enabling it ought to create a split tunnel, for any subnets defined within this tab to be routed via the VPN, but everything else to be routed via the default route. When Hilco enabled it he obtained this route table: $ 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 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 The above does not offer him a route into the company's LAN and he cannot connect to the servers *.i.company.com. When the above setting is left disabled, then Hilco can access the company domain, but not the Internet - a full tunnel. His route table now shows tun0 as being the default NIC: $ 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 > > because this creates a full tunnel. > > What does "full tunnel" mean to you? > > I would think that it's the same tunnel, just different traffic routed > through it. My understanding of a "split tunnel" or "split horizon" as you call it involves two routes: 1. Route for connections via the VPN tunnel: One route is used to direct datagrams from a local subnet or a virtual VPN IP allocated by the remote VPN gateway, e.g. $SOME_COMPANY_IP_1, via the VPN tunnel (tun0) to the remote company's LAN. 2. Route for all other connections, outside the VPN tunnel: A second route is typically the default route of the PC for all other connections and it is used to route datagrams outside the VPN tunnel. Some VPN clients add a new routing policy rule table (e.g. strongswan), but others (e.g. racoon) add routes for the VPN tunnel in the main routing policy rule table. In contrast, a "full tunnel" directs all outgoing datagrams from any local subnet via the VPN. I appreciate what I describe above is inverse to what the setting "Use only for resources on this connection" is meant to do, but I merely go by the route tables Hilco has provided. Hmm ... prompted by your question in this post I had to give it a second thought, and I've come up with this hypothesis: IF no specific subnet routes are defined on the NM routes tab AND the "Use only for resources on this connection" is selected, then it may be that networkmanager translates no subnet entry to mean 0.0.0.0/0 - ALL routes will be tunneled via the VPN, leaving nothing for the default route. Without more information on NM's specific settings I'm not sure why routing is screwed up like this. :-) Nevertheless, adding a route manually for the remote LAN subnet as per my previous post should deliver a 'split tunnel/horizon', assuming the DNS nameservers are also somehow sorted out. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/17/2018 03:05 PM, Mick wrote: TBH I wouldn't select "Use only for resources on this connection", I thought "Use only for resources on this connection" would enable (what I know as) "split horizon", which is what I thought the OP wanted to do. In other words route company traffic through the VPN and route everything not to the company via the ISP. because this creates a full tunnel. What does "full tunnel" mean to you? I would think that it's the same tunnel, just different traffic routed through it. -- Grant. . . . unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
Hilco, I don't know if this thread was resolved - additional suggestions posted below. On Saturday, 9 June 2018 01:20:18 BST Hilco Wijbenga wrote: > 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 > 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 > $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. In the above setup you need to define a route for the subnet of your company's LAN. For example, if the LAN of your company is 10.0.20.0/24: ip route add 10.0.20.0/24 via $SOME_COMPANY_IP_1 dev tun0 should push all connections to your company's LAN via the tunnel tun0. Two commands to help you see what routes your VPN client is setting up are: ip rule list which may list some new tables (in addition to local, main and default), if your VPN client has set these up. Then look at the contents of said table, e.g.: ip route show table 220 Not all clients create separate rules, so the changes may have been added to the main rule table. If in doubt and don't mind some noise look at all the tables: ip route show table all NOTE: If you are accessing your company's LAN/servers using a FQDN instead of private IP addresses, then you will need to configure the appropriate nameserver for your company. Check what has been entered in /etc/resolv.conf. > Same setup but without "Use only for resources on this connection": > $ ip route > default dev tun0 proto static scope link metric 50 Device tun0 has a higher metric than your physical eth0 device below. I expect all connections which can be routed via tun0 will be routed so. > default via 192.168.151.1 dev eth0 proto static metric 100 I'm not sure if this will work, but you can try changing the metric of device eth0, so it takes precedence to tun0; e.g.: ip route replace default via 192.168.151.1 dev eth0 proto static metric 30 ip route show ip route delete 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) > ==> This allows me to access *.i.company.com but breaks everything else. I expect it breaks everything else (connections to anything outside you company's LAN) because everything is sent out tun0 which has a higher priority than your eth0, but your company's routing on the other side, once it receives the packets, does not allow outgoing connections from your allocated $SOME_COMPANY_IP_2 to the Internet. TBH I wouldn't select "Use only for resources on this connection", because this creates a full tunnel. > What would be the "correct" output for "ip route"? Different VPN clients create rules and entries in different tables, so there isn't a straight forward "correct" ip route output. In any case, using 'ip route show table all' you should be able to see a route which allows connections to your company's LAN subnet to be sent out via tun0 and connections to the rest of the world to be routable via your eth0. What VPN client are you using? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/12/2018 09:17 AM, Hilco Wijbenga wrote:
Okay, I've got it mostly working now. The missing route seems to be
"10.0.0.0", "255.0.0.0", "0.0.0.0", "100".
255.0.0.0/8 is special and 0.0.0.0/0 is very special.
255/8 is not globally routed and contains 255.255.255.255 which is used
as a broadcast address.
So not the gateway but 0.0.0.0.
0/0 is functionally equivalent to the default gateway.
This works both in Gentoo and VirtualBox ... except for (at least)
one internal site.
I have a.i.company.com ("a") and b.i.company.com ("b"). Dig in Gentoo
tells me both are aliases for a.r1.i.company.com and b.r1.i.company.com,
respectively. They both resolve to 10.x.y.z addresses. But "a" works
in both Gentoo and VB, while "b" cannot be resolved in VB (dig finds
nothing). I can obviously work around that but I'm very confused why it
doesn't work the same in both.
It sounds like you also need to route 10/8 in addition to the
aforementioned prefixes.
I find it suspect that "b" doesn't work. I wonder if it's related to
the DNS server that you're querying, specifically if it's internal /
external and if it's routed through the VPN too.
--
Grant. . . .
unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
Okay, I've got it mostly working now. The missing route seems to be
"10.0.0.0", "255.0.0.0", "0.0.0.0", "100". So not the gateway but
0.0.0.0. This works both in Gentoo and VirtualBox ... except for (at
least) one internal site.
I have a.i.company.com ("a") and b.i.company.com ("b"). Dig in Gentoo
tells me both are aliases for a.r1.i.company.com and
b.r1.i.company.com, respectively. They both resolve to 10.x.y.z
addresses. But "a" works in both Gentoo and VB, while "b" cannot be
resolved in VB (dig finds nothing). I can obviously work around that
but I'm very confused why it doesn't work the same in both.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/11/2018 06:50 PM, Alarig Le Lay wrote: The “dev” syntax is correct. As tun0 is a L3 tunnel, you don’t have to bother about ARP next-hop resolution. Thank you for the confirmation Alarig. -- Grant. . . . unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
So, from what I’m reading in the thread you need three things: 1. Look at what are the internal ranges used at work 2. Disable the default route to the VPN 3. For each range, add a route like 'ip route add $range dev tun0' For the last part, it should be a good idea to create a up script to avoid adding routes at each connexion. 4. bonus part, tell you IT department to push internal routes and not the default one -- alarig signature.asc Description: PGP signature
Re: [gentoo-user] Enable "regular" network traffic when using VPN
Hi, On ven. 8 juin 18:34:14 2018, Grant Taylor wrote: > I'd then reconfigure the VPN with "Use only for resources on this > connection." and then do something like this: > > I'm not completely sure about the "dev" syntax as it's been a while since > I've done routes via devices. Check IP's man page. The “dev” syntax is correct. As tun0 is a L3 tunnel, you don’t have to bother about ARP next-hop resolution. -- alarig signature.asc Description: PGP signature
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/11/2018 02:51 PM, Mick wrote: As I understand it, the CGN router will rewrite the IP headers and ports from/ to the SOHO router using PCP. This is not a TCP-over-TCP tunnel. The VPN could be TCP based and it could be sending TCP through it. Yes, the potential pitfalls of TCP-in-TCP may apply. Just because it's sub-optimal doesn't mean that it won't work. Outgoing connections will be OK, but to run a local server I believe you'll need to set up an external 'rendezvous server' to facilitate incoming connections, since the double NAT'ed local server will not have a public facing IP address. The NATed server doesn't need a globally routed IP if there is port forwarding in place. Such is possible, all be it unlikely, with multiple layers of NAT. I still think the OP was talking about (multiple layers of) NAT at his end and connecting to a VPN server at his office that had a globally routed IP address. Besides, the OP did state that he was able to connect and that traffic did flow bidirectionally through the VPN. I'm trying to recall what I was thinking when I wrote this ... SSH reverse tunneling? Not sure. Outgoing VPN connections *should* work fine, incoming won't. Incoming VPN connections can be made to work. They will require significantly more effort and cooperation of the NAT administrators. Besides, this is outside of the OP's use case. I've tried that and couldn't get it to work - for reasons I explained below. I've lost what your referring to there. Yes, in these cases you have to use different ports and set port forwarding per client. Not all VPN protocols have the concept of ports and as such can't use different ports. -- Grant. . . . unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Monday, 11 June 2018 17:47:16 BST Grant Taylor wrote: > On 06/11/2018 04:55 AM, Mick wrote: > > You'll need a trusted gateway to do the unwrapping and then forwarding > > to the next hop (SSH forwarding). If you attempt TCP-tunneling > > (TCP-over-TCP) you'll soon experience 'TCP meltdown' with upper and > > lower TCP layers' retransmission timeouts. > > I disagree. > > If I can establish an HTTPS (or other TCP connection to carry TLS > traffic) out through multiple layers of NAT (SOHO router + CGN + ???) to > a server with a globally routed IP address, I should be golden. > > NAT will do what it needs to with the internal IPs to establish the > connection from the deeply buried client out to the TLS VPN server. As I understand it, the CGN router will rewrite the IP headers and ports from/ to the SOHO router using PCP. This is not a TCP-over-TCP tunnel. > The connection will (extremely likely) be kept alive with various > different methods (TCP keep alive or VPN keep alive or pings through the > VPN) such that the upstream gateway can send data back to the client > through the established VPN. Outgoing connections will be OK, but to run a local server I believe you'll need to set up an external 'rendezvous server' to facilitate incoming connections, since the double NAT'ed local server will not have a public facing IP address. > Arguably this is no different than a long lived HTTP(S) connection from > the same client deep behind multiple NATs. > > There is no need for something in the middle to unwrap things. I'm trying to recall what I was thinking when I wrote this ... SSH reverse tunneling? Not sure. Outgoing VPN connections *should* work fine, incoming won't. > It almost sounds like you're talking about trying to do something from > one computer behind one or more NATs to another computer behind one or > more NATs on the far end. — That is a far more complex and > significantly different problem. I've tried that and couldn't get it to work - for reasons I explained below. > Most corporate VPN users are road warriors and connect from random IPs > to a static globally routed IP that is open to the world. > > > How will you be able to account for such a multi-NAT routing arrangement > > if (in tunnel rather than transport mode) the original entire IP datagram > > is encrypted and encapsulated? You'll need to decrypt it, take the > > payload and read its IP header before you know where to forward it to. > > Let me know if my comments above don't answer your question. > > > On single NAT you encapsulate the IPSec into UDP (NAT-Traversal), but > > on a double NAT what will you do? > > On the second NAT, you pass the UDP traffic from the first NAT. > > > I've never heard of double/triple NAT-T without port forwarding ... > > There is no specific need for port forwarding in any of the NATs when > the traffic is originated outbound from the innermost client going out > to a static globally routed IP. — Just like there's no need for it > when making an HTTPS request from the same client system. > > > Do you mean VPN within UDP within VPN? You'll need intermediate VPN > > gateways for this. > > No. L2TP and / or PPTP are notoriously flaky with NATs. But it's > usually possible to get a single L2TP / PPTP VPN to function behind a > NAT. This is because the NAT sees the L2TP or PPTP traffic and > associates it with a single VPN client behind the NAT. If (when) there > is a second VPN client of the same type, it breaks the association of > which internal client the traffic goes to. Thus it usually breaks / > prevents all such clients from working at the same time. Yes, in these cases you have to use different ports and set port forwarding per client. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/11/2018 04:55 AM, Mick wrote: You'll need a trusted gateway to do the unwrapping and then forwarding to the next hop (SSH forwarding). If you attempt TCP-tunneling (TCP-over-TCP) you'll soon experience 'TCP meltdown' with upper and lower TCP layers' retransmission timeouts. I disagree. If I can establish an HTTPS (or other TCP connection to carry TLS traffic) out through multiple layers of NAT (SOHO router + CGN + ???) to a server with a globally routed IP address, I should be golden. NAT will do what it needs to with the internal IPs to establish the connection from the deeply buried client out to the TLS VPN server. The connection will (extremely likely) be kept alive with various different methods (TCP keep alive or VPN keep alive or pings through the VPN) such that the upstream gateway can send data back to the client through the established VPN. Arguably this is no different than a long lived HTTP(S) connection from the same client deep behind multiple NATs. There is no need for something in the middle to unwrap things. It almost sounds like you're talking about trying to do something from one computer behind one or more NATs to another computer behind one or more NATs on the far end. — That is a far more complex and significantly different problem. Most corporate VPN users are road warriors and connect from random IPs to a static globally routed IP that is open to the world. How will you be able to account for such a multi-NAT routing arrangement if (in tunnel rather than transport mode) the original entire IP datagram is encrypted and encapsulated? You'll need to decrypt it, take the payload and read its IP header before you know where to forward it to. Let me know if my comments above don't answer your question. On single NAT you encapsulate the IPSec into UDP (NAT-Traversal), but on a double NAT what will you do? On the second NAT, you pass the UDP traffic from the first NAT. I've never heard of double/triple NAT-T without port forwarding ... There is no specific need for port forwarding in any of the NATs when the traffic is originated outbound from the innermost client going out to a static globally routed IP. — Just like there's no need for it when making an HTTPS request from the same client system. Do you mean VPN within UDP within VPN? You'll need intermediate VPN gateways for this. No. L2TP and / or PPTP are notoriously flaky with NATs. But it's usually possible to get a single L2TP / PPTP VPN to function behind a NAT. This is because the NAT sees the L2TP or PPTP traffic and associates it with a single VPN client behind the NAT. If (when) there is a second VPN client of the same type, it breaks the association of which internal client the traffic goes to. Thus it usually breaks / prevents all such clients from working at the same time. -- Grant. . . . unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Sunday, 10 June 2018 23:51:42 BST Grant Taylor wrote: > On 06/10/2018 12:30 PM, Mick wrote: > > If NAT'ed between guest and host and then NAT'ed again at the home > > router, you are double NAT'ed. > > Or possibly triple NATed if your ISP is using Carrier Grade NAT. > > At least that's one definition of "double NAT". I tend to use a > different definition, one where you're NATing source and destination in > a single device. As opposed to doing a single NAT operation on multiple > devices. > > > As far as I know VPNs will not work through a double NAT situation, > > unless you use your gateway or host as the VPN end point and then > > setup port forwarding to the host from there. > > I see no reason why SSL or SSH based VPNs wouldn't work perfectly fine > through many layers of NAT. You'll need a trusted gateway to do the unwrapping and then forwarding to the next hop (SSH forwarding). If you attempt TCP-tunneling (TCP-over-TCP) you'll soon experience 'TCP meltdown' with upper and lower TCP layers' retransmission timeouts. > I also think that it should be possible to get IPSec VPNs to work > through multiple layers of NAT. You'd need to account for the AH issues > or ESP without AH. How will you be able to account for such a multi-NAT routing arrangement if (in tunnel rather than transport mode) the original entire IP datagram is encrypted and encapsulated? You'll need to decrypt it, take the payload and read its IP header before you know where to forward it to. On single NAT you encapsulate the IPSec into UDP (NAT-Traversal), but on a double NAT what will you do? I've never heard of double/triple NAT-T without port forwarding ... > Each layer of NAT makes VPNs more difficult, but not impossible. > > Depending on the type of VPN, each layer of NAT may mean that you must > be the only person using that type of VPN to avoid confusing the NAT / > breaking all of that type of VPN. Do you mean VPN within UDP within VPN? You'll need intermediate VPN gateways for this. > > Bridge the host to guest adaptors and you should be good to go (once > > any other conventionla VPN configuration problem is solved). :-) > > Hilco's issue was what is routed through the VPN, not a problem with > establishing said VPN. Quite, we've gone off-piste here. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/10/2018 12:30 PM, Mick wrote: If NAT'ed between guest and host and then NAT'ed again at the home router, you are double NAT'ed. Or possibly triple NATed if your ISP is using Carrier Grade NAT. At least that's one definition of "double NAT". I tend to use a different definition, one where you're NATing source and destination in a single device. As opposed to doing a single NAT operation on multiple devices. As far as I know VPNs will not work through a double NAT situation, unless you use your gateway or host as the VPN end point and then setup port forwarding to the host from there. I see no reason why SSL or SSH based VPNs wouldn't work perfectly fine through many layers of NAT. I also think that it should be possible to get IPSec VPNs to work through multiple layers of NAT. You'd need to account for the AH issues or ESP without AH. Each layer of NAT makes VPNs more difficult, but not impossible. Depending on the type of VPN, each layer of NAT may mean that you must be the only person using that type of VPN to avoid confusing the NAT / breaking all of that type of VPN. Bridge the host to guest adaptors and you should be good to go (once any other conventionla VPN configuration problem is solved). :-) Hilco's issue was what is routed through the VPN, not a problem with establishing said VPN. -- Grant. . . . unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Sun, Jun 10, 2018 at 11:08 AM Wol's lists wrote: > > On 10/06/18 17:53, Mick wrote: > > On Sunday, 10 June 2018 01:31:50 BST Hilco Wijbenga wrote: > >> Okay, with all that advice, I gave it another try. I'm also setting up > >> a VirtualBox for my WFH stuff and VB wants to use 10.0.0.0 for its > >> networking. I've changed this to 172.16.0.0 so now I can easily tell > >> that network from work network (which seems to use 10.25.0.0) > >> > >> I wanted to add a route to NetworkManager's VPN connection. It wants > >> Address, Network, Gateway, and Metric so I gave it "10.0.0.0", > >> "255.0.0.0" (this one shows up automatically), "207.x.y.z", "1". But > >> then VPN fails to start with the complaint that the configuration is > >> invalid. > >> > >> So I tried what I think is the same on the CL: > >> > >> $> route add -net 10.0.0.0/8 gw "207.x.y.z" metric 1 > >> SIOCADDRT: Network is unreachable > >> > >> So apparently, it's not quite as straightforward as I thought it might be. > >> :-) > > > > Ahh! If you're trying to set this up within a VM, this adds a whole new > > layer > > of complexity. I assume you're setting up a bridge between host and guest > > device(s)? > > > No if he's assigned 172.16/16 to the VM network he hasn't. VB defaults > to a NAT'd network and it's always given me grief. I was going to > suggest he switched to bridged. > > In settings, change the network adaptor type to bridged, and then the VM > will get its settings and IP address from the DHCP server serving the > local network. Makes things MUCH easier. I've changed it to "Bridged Adapter" but the behaviour is exactly the same as before. I'm guessing I still need an extra "route" (or two). Any ideas about that?
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Sun, Jun 10, 2018 at 11:31 AM Mick wrote: > > On Sunday, 10 June 2018 19:07:59 BST Wol's lists wrote: > > On 10/06/18 17:53, Mick wrote: > > > On Sunday, 10 June 2018 01:31:50 BST Hilco Wijbenga wrote: > > >> Okay, with all that advice, I gave it another try. I'm also setting up > > >> a VirtualBox for my WFH stuff and VB wants to use 10.0.0.0 for its > > >> networking. I've changed this to 172.16.0.0 so now I can easily tell > > >> that network from work network (which seems to use 10.25.0.0) > > >> > > >> I wanted to add a route to NetworkManager's VPN connection. It wants > > >> Address, Network, Gateway, and Metric so I gave it "10.0.0.0", > > >> "255.0.0.0" (this one shows up automatically), "207.x.y.z", "1". But > > >> then VPN fails to start with the complaint that the configuration is > > >> invalid. > > >> > > >> So I tried what I think is the same on the CL: > > >> > > >> $> route add -net 10.0.0.0/8 gw "207.x.y.z" metric 1 > > >> SIOCADDRT: Network is unreachable > > >> > > >> So apparently, it's not quite as straightforward as I thought it might > > >> be. > > >> > > >> :-) > > > > > > Ahh! If you're trying to set this up within a VM, this adds a whole new > > > layer of complexity. I assume you're setting up a bridge between host > > > and guest device(s)? > > > > No if he's assigned 172.16/16 to the VM network he hasn't. VB defaults > > to a NAT'd network and it's always given me grief. I was going to > > suggest he switched to bridged. > > > > In settings, change the network adaptor type to bridged, and then the VM > > will get its settings and IP address from the DHCP server serving the > > local network. Makes things MUCH easier. > > > > Cheers, > > Wol > > If NAT'ed between guest and host and then NAT'ed again at the home router, you > are double NAT'ed. As far as I know VPNs will not work through a double NAT > situation, unless you use your gateway or host as the VPN end point and then > setup port forwarding to the host from there. Bridge the host to guest > adaptors and you should be good to go (once any other conventionla VPN > configuration problem is solved). :-) In what sense does it "not work"? I can connect just fine. If I change VB's networking to "Bridged Adapter" I don't get any different behaviour. (I would prefer to avoid fooling around with my main OS's networking so the VB route seems "safer".)
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Sun, Jun 10, 2018 at 10:03 AM Grant Taylor wrote: > > On 06/09/2018 06:31 PM, Hilco Wijbenga wrote: > > Okay, with all that advice, I gave it another try. I'm also setting > > up a VirtualBox for my WFH stuff and VB wants to use 10.0.0.0 for its > > networking. I've changed this to 172.16.0.0 so now I can easily tell > > that network from work network (which seems to use 10.25.0.0) > > > > I wanted to add a route to NetworkManager's VPN connection. It wants > > Address, Network, Gateway, and Metric so I gave it "10.0.0.0", "255.0.0.0" > > (this one shows up automatically), "207.x.y.z", "1". But then VPN fails > > to start with the complaint that the configuration is invalid. > > > > So I tried what I think is the same on the CL: > > > > $> route add -net 10.0.0.0/8 gw "207.x.y.z" metric 1 > > SIOCADDRT: Network is unreachable > > > > So apparently, it's not quite as straightforward as I thought it might > > be. :-) > > I think you're actually quite close. > > I believe the reason NetworkManager's VPN and the route command are > complaining are the same. > > Routing almost always wants the next hop, not the ultimate destination. > > Think about it this way, if you ask for directions in an unfamiliar > building, do you want to be told that you need to go to the office > across the hall from Mary? Or do you want to be told, take the elevator > tot he 4th floor, turn left, and go to the office across the haul from > Mary, she has a big sign on her office. > > "Across the haul from Mary" by itself is useless and unactionable. The > directions that start with the elevator in the lobby is actionable. ;-) Okay, that makes sense, I suppose. What is the next hop? I've googled and googled but I did not find any examples of how to set this up. AFAICT, you're simply supposed to check the "Use only for resources on this connection" checkbox and you're done.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Sunday, 10 June 2018 19:07:59 BST Wol's lists wrote: > On 10/06/18 17:53, Mick wrote: > > On Sunday, 10 June 2018 01:31:50 BST Hilco Wijbenga wrote: > >> Okay, with all that advice, I gave it another try. I'm also setting up > >> a VirtualBox for my WFH stuff and VB wants to use 10.0.0.0 for its > >> networking. I've changed this to 172.16.0.0 so now I can easily tell > >> that network from work network (which seems to use 10.25.0.0) > >> > >> I wanted to add a route to NetworkManager's VPN connection. It wants > >> Address, Network, Gateway, and Metric so I gave it "10.0.0.0", > >> "255.0.0.0" (this one shows up automatically), "207.x.y.z", "1". But > >> then VPN fails to start with the complaint that the configuration is > >> invalid. > >> > >> So I tried what I think is the same on the CL: > >> > >> $> route add -net 10.0.0.0/8 gw "207.x.y.z" metric 1 > >> SIOCADDRT: Network is unreachable > >> > >> So apparently, it's not quite as straightforward as I thought it might > >> be. > >> > >> :-) > > > > Ahh! If you're trying to set this up within a VM, this adds a whole new > > layer of complexity. I assume you're setting up a bridge between host > > and guest device(s)? > > No if he's assigned 172.16/16 to the VM network he hasn't. VB defaults > to a NAT'd network and it's always given me grief. I was going to > suggest he switched to bridged. > > In settings, change the network adaptor type to bridged, and then the VM > will get its settings and IP address from the DHCP server serving the > local network. Makes things MUCH easier. > > Cheers, > Wol If NAT'ed between guest and host and then NAT'ed again at the home router, you are double NAT'ed. As far as I know VPNs will not work through a double NAT situation, unless you use your gateway or host as the VPN end point and then setup port forwarding to the host from there. Bridge the host to guest adaptors and you should be good to go (once any other conventionla VPN configuration problem is solved). :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 10/06/18 17:53, Mick wrote: On Sunday, 10 June 2018 01:31:50 BST Hilco Wijbenga wrote: Okay, with all that advice, I gave it another try. I'm also setting up a VirtualBox for my WFH stuff and VB wants to use 10.0.0.0 for its networking. I've changed this to 172.16.0.0 so now I can easily tell that network from work network (which seems to use 10.25.0.0) I wanted to add a route to NetworkManager's VPN connection. It wants Address, Network, Gateway, and Metric so I gave it "10.0.0.0", "255.0.0.0" (this one shows up automatically), "207.x.y.z", "1". But then VPN fails to start with the complaint that the configuration is invalid. So I tried what I think is the same on the CL: $> route add -net 10.0.0.0/8 gw "207.x.y.z" metric 1 SIOCADDRT: Network is unreachable So apparently, it's not quite as straightforward as I thought it might be. :-) Ahh! If you're trying to set this up within a VM, this adds a whole new layer of complexity. I assume you're setting up a bridge between host and guest device(s)? No if he's assigned 172.16/16 to the VM network he hasn't. VB defaults to a NAT'd network and it's always given me grief. I was going to suggest he switched to bridged. In settings, change the network adaptor type to bridged, and then the VM will get its settings and IP address from the DHCP server serving the local network. Makes things MUCH easier. Cheers, Wol
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/10/2018 10:53 AM, Mick wrote: Ahh! If you're trying to set this up within a VM, this adds a whole new layer of complexity. I assume you're setting up a bridge between host and guest device(s)? Yes, VMs can add additional complexity to the situation. However I suspect that's not the problem in this case. The nice thing about VPNs is that they are tunnels from points A and A. So as long as A knows how to get to Z and vice versa, things should be good. A needs to know to pass through B to get to Z and Z needs to know to pass through Y to get to A. About the only caveat that comes to mind is if things like IPSec are in use and there are things between A and Z that interfere with the IPSec traffic. (Maliciously or accidentally.) Grant may be better equipped to answer here how to configure this, ~deer~in~the~headlights~look~ "Huh? What? Me‽" *gulp* … *dry*mouth* it is beyond my amateurish skills ... You're not as amateurish as you pretend to think you are. ;-) -- Grant. . . . unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/09/2018 06:31 PM, Hilco Wijbenga wrote: Okay, with all that advice, I gave it another try. I'm also setting up a VirtualBox for my WFH stuff and VB wants to use 10.0.0.0 for its networking. I've changed this to 172.16.0.0 so now I can easily tell that network from work network (which seems to use 10.25.0.0) I wanted to add a route to NetworkManager's VPN connection. It wants Address, Network, Gateway, and Metric so I gave it "10.0.0.0", "255.0.0.0" (this one shows up automatically), "207.x.y.z", "1". But then VPN fails to start with the complaint that the configuration is invalid. So I tried what I think is the same on the CL: $> route add -net 10.0.0.0/8 gw "207.x.y.z" metric 1 SIOCADDRT: Network is unreachable So apparently, it's not quite as straightforward as I thought it might be. :-) I think you're actually quite close. I believe the reason NetworkManager's VPN and the route command are complaining are the same. Routing almost always wants the next hop, not the ultimate destination. Think about it this way, if you ask for directions in an unfamiliar building, do you want to be told that you need to go to the office across the hall from Mary? Or do you want to be told, take the elevator tot he 4th floor, turn left, and go to the office across the haul from Mary, she has a big sign on her office. "Across the haul from Mary" by itself is useless and unactionable. The directions that start with the elevator in the lobby is actionable. ;-) -- Grant. . . . unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Sunday, 10 June 2018 01:31:50 BST Hilco Wijbenga wrote: > Okay, with all that advice, I gave it another try. I'm also setting up > a VirtualBox for my WFH stuff and VB wants to use 10.0.0.0 for its > networking. I've changed this to 172.16.0.0 so now I can easily tell > that network from work network (which seems to use 10.25.0.0) > > I wanted to add a route to NetworkManager's VPN connection. It wants > Address, Network, Gateway, and Metric so I gave it "10.0.0.0", > "255.0.0.0" (this one shows up automatically), "207.x.y.z", "1". But > then VPN fails to start with the complaint that the configuration is > invalid. > > So I tried what I think is the same on the CL: > > $> route add -net 10.0.0.0/8 gw "207.x.y.z" metric 1 > SIOCADDRT: Network is unreachable > > So apparently, it's not quite as straightforward as I thought it might be. > :-) Ahh! If you're trying to set this up within a VM, this adds a whole new layer of complexity. I assume you're setting up a bridge between host and guest device(s)? Grant may be better equipped to answer here how to configure this, it is beyond my amateurish skills ... -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
Okay, with all that advice, I gave it another try. I'm also setting up a VirtualBox for my WFH stuff and VB wants to use 10.0.0.0 for its networking. I've changed this to 172.16.0.0 so now I can easily tell that network from work network (which seems to use 10.25.0.0) I wanted to add a route to NetworkManager's VPN connection. It wants Address, Network, Gateway, and Metric so I gave it "10.0.0.0", "255.0.0.0" (this one shows up automatically), "207.x.y.z", "1". But then VPN fails to start with the complaint that the configuration is invalid. So I tried what I think is the same on the CL: $> route add -net 10.0.0.0/8 gw "207.x.y.z" metric 1 SIOCADDRT: Network is unreachable So apparently, it's not quite as straightforward as I thought it might be. :-)
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Saturday, 9 June 2018 01:20:18 BST Hilco Wijbenga wrote:
> On Fri, Jun 8, 2018 at 4:34 PM Mick 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
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/08/2018 06:20 PM, Hilco Wijbenga wrote: What would be the "correct" output for "ip route"? It's difficult to say. I'd look up some of the *.i.company.com names and see what IP addresses they resolve to. I'd then reconfigure the VPN with "Use only for resources on this connection." and then do something like this: ip route add 172.16.0.0/24 dev tun0 Adjust 172.16.0.0 and /24 as appropriate for your company. I'm not completely sure about the "dev" syntax as it's been a while since I've done routes via devices. Check IP's man page. The ides is that you want just the IP address space that your company uses to be routed through the VPN and everything else to go out your default gateway (192.168.151.1). -- Grant. . . . unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Fri, Jun 8, 2018 at 4:34 PM Mick 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.company.com,r6.i.company.com,r7.i.company.com,r8.i.company.com,i.company.com,config)
$ 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
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
$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)
==> This allows me to access *.i.company.com but breaks everything else.
What would be the "correct" output for "ip route"?
Re: [gentoo-user] Enable "regular" network traffic when using VPN
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. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
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. -- Grant. . . . unix || die
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Fri, Jun 8, 2018 at 2:19 PM Hilco Wijbenga wrote: > > On Fri, Jun 8, 2018 at 1:59 PM Grant Taylor > wrote: > > > Any ideas? > > > > My bet is routing. Specifically the default gateway probably gets > > changed to route through the VPN when connected. > > > > You may want to reconfigure the VPN client to only route work prefixes > > through the VPN and let everything else go through your local default > > gateway. > > > > Note: What I'm suggesting is typically called "Split Horizon" routing / > > VPN. > > Yup, "Use only for resources on this connection" seems to have done > the trick. Thanks! Sigh, I take it back. That causes the internal sites to no longer work.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Fri, Jun 8, 2018 at 1:59 PM Grant Taylor wrote: > > Any ideas? > > My bet is routing. Specifically the default gateway probably gets > changed to route through the VPN when connected. > > You may want to reconfigure the VPN client to only route work prefixes > through the VPN and let everything else go through your local default > gateway. > > Note: What I'm suggesting is typically called "Split Horizon" routing / > VPN. Yup, "Use only for resources on this connection" seems to have done the trick. Thanks!
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/08/2018 01:42 PM, Hilco Wijbenga wrote: Hi all, Hi Hilco, I am logging all DNS requests and I can see that dnsmasq is responding correctly (and, in fact, identically) to, say, google.com with or without VPN. But the browser just hangs. Until I disconnect VPN, then everything works again. So it seems that I'm close but something is still missing. Any ideas? My bet is routing. Specifically the default gateway probably gets changed to route through the VPN when connected. You may want to reconfigure the VPN client to only route work prefixes through the VPN and let everything else go through your local default gateway. Note: What I'm suggesting is typically called "Split Horizon" routing / VPN. -- Grant. . . . unix || die
