Re: [Openvpn-users] I can reach only part of the local LAN when connected

2022-10-02 Thread Bo Berglund 
On Sun, 02 Oct 2022 09:59:59 -0400, Bo Berglund  wrote:

>Now being outside both of these LAN sections over in the USA I can connect my
>laptop to my main vpn server on the 119 LAN and it works just fine for
>everything on the 119 LAN, but now the 117 segment is inaccessible
>
>This is the problem I am trying to fix, since I need to reach a server on the
>117 segment using a browser on my Win10 laptop and that is only possible via 
>the
>tunnel between the two LAN sections.

For some reason, after I disconnected the VPN and then connected it again from
my Windows10 laptop to the split tunnel connection everything started working!

I do not understand it since I have not made any changes to the configurations
inbetween...

Now I can reach the remote LAN (117) from my laptop when it is connected by VPN
to the home network (119).
SSH directly from Windows to the remote LAN devices works and also a web browser
access to the remote LAN (117) router's config pages.

Did not work when I started this thread.

Sorry for the noise.

-- 
Bo Berglund
Developer in Sweden



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] I can reach only part of the local LAN when connected

2022-10-02 Thread Doug Lytle 

On 10/2/22 07:42, Bo Berglund wrote:

What could I change to make it work?


I suggest you use traceroute to see what paths the data are taking.

Doug
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] I can reach only part of the local LAN when connected

2022-10-02 Thread Bo Berglund 
On Sun, 2 Oct 2022 07:55:42 -0400, Joe Patterson 
wrote:

>This may be a stupid question, but in the remote office, do you have a
>route for 10.8.139.0/25? If not, then the clients can get packets to
>the remote network, but the remote network can't get packets back to
>the clients.
>

I think the routing at the 117 site is correctly set up...

When my laptop is hooked up at home to the 119 LAN it has full connectivity to
all devices on the 117 LAN and when it is connected to the 117 LAN it can
connect fine to everything on the 119 LAN.
This works through the OpenVPN tunnel set up by the router on the 117 LAN to my
main OpenVPN server on my home LAN (119). Both of tese routers have routing set
up for the other side LAN.

It has worked fine all throuh the summer when I lived at the 117 location even
for heavy-duty weekly backups towards a NAS sitting on the 119 LAN.

The two locations are spaced 100 km apart and both have fiber connections
250/250 Mbps.

And when I moved back home to 119 I still had transparent connection to all
devices on the 117 LAN, so the basics seems to be set up correctly (at least in
working order).

Now being outside both of these LAN sections over in the USA I can connect my
laptop to my main vpn server on the 119 LAN and it works just fine for
everything on the 119 LAN, but now the 117 segment is inaccessible

This is the problem I am trying to fix, since I need to reach a server on the
117 segment using a browser on my Win10 laptop and that is only possible via the
tunnel between the two LAN sections.

NOTE:
If I open an ssh session to my openvpn server or another linux box at my home
LAN (119) then I can log on to the server at the 117 LAN via ssh from that
session.
But I need the web interface from my windows box so I must be able to dirctly
access the 117 LAN when I am remotely connected by VPN in order to modify some
items like the 117 router config...


-- 
Bo Berglund
Developer in Sweden



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] I can reach only part of the local LAN when connected

2022-10-02 Thread Joe Patterson 
This may be a stupid question, but in the remote office, do you have a
route for 10.8.139.0/25? If not, then the clients can get packets to
the remote network, but the remote network can't get packets back to
the clients.

On Sun, Oct 2, 2022 at 7:44 AM Bo Berglund  wrote:
>
> 6 months ago or so I have set up a system where I have two fiber connected LAN
> segments in different locations tied together with OpenVPN into one single LAN
> using addresses 192.168.117.x and 192.168.119.x.
>
> The two segments have routers configured such that the 117 LAN connects with
> OpenVPN to my main LAN on 119 and the main LAN router has its routing set up 
> to
> channel traffic for 117 via the OpenVPN tunnel.
>
> It works well for devices connected to the two LAN sections directly, but not
> when a device is connected to the main LAN via OpenVPN while travelling.
> In this case (I am now half a workld away from home) I can reach my home LAN
> (119) but not the 117 LAN...
>
> So now I wonder how I should set up the OpenVPN server on the main LAN such 
> that
> if a client wants to talk to a device on the 117 segment it can actually reach
> it?
>
> The server is set up for a split tunnel such that if a client addresses the
> server side LAN it will route through the tunnel but for Internet traffic it
> should use the local gateway directly.
> Now I think that it is actually doing this for traffic to LAN segment 117 too
> and this is what I would like to change.
>
> Here is my server side conf file:
>
> # this is the config for local only access
> port 1190
> proto udp
> dev tun
> ca /etc/openvpn/keys/ca.crt
> cert /etc/openvpn/keys/server.crt
> key /etc/openvpn/keys/server.key
> dh /etc/openvpn/keys/dh2048.pem
> tls-auth /etc/openvpn/keys/ta.key 0
> topology subnet
> server 10.8.139.0 255.255.255.0  'nopool'
> ifconfig-pool 10.8.139.2 10.8.139.127 255.255.255.0
> ifconfig-pool-persist ipplocal.txt
> push "route 192.168.119.0 255.255.255.0" #Local LAN access
> push "dhcp-option DNS 192.168.119.1" #Local server
> push "dhcp-option DNS 208.67.220.220" #Public server
> keepalive 10 120
> cipher AES-256-CBC
> #Disable compression and push this to the client
> comp-lzo no
> push "comp-lzo no"
>
> # This is needed for site-to-site routing via remote Router
> client-config-dir /etc/openvpn/ccdl
> route 192.168.117.0 255.255.255.0
> # Allow other clients to the server to also reach remote
> client-to-client
> push "route 192.168.117.0 255.255.255.0"
> # end site-to-site routing
> max-clients 20
> persist-key
> persist-tun
> status /etc/openvpn/log/ovpn-status_local.log
> log /etc/openvpn/log/ovpn_local.log
> verb 4
> mute 10
> explicit-exit-notify 1
> push "explicit-exit-notify 1"
>
> It seems like the following line does not affect the connected VPN clients on
> the server LAN:
> route 192.168.117.0 255.255.255.0
>
> What could I change to make it work?
>
> Can this line be modified to encompass a larger subnet maybe?
> push "route 192.168.119.0 255.255.255.0" #Local LAN access
>
> for example 192.168.116.0/22 (covering 116, 117, 118, 119)
>
>
> --
> Bo Berglund
> Developer in Sweden
>
>
>
> ___
> Openvpn-users mailing list
> Openvpn-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Openvpn-users] I can reach only part of the local LAN when connected

2022-10-02 Thread Bo Berglund 
6 months ago or so I have set up a system where I have two fiber connected LAN
segments in different locations tied together with OpenVPN into one single LAN
using addresses 192.168.117.x and 192.168.119.x.

The two segments have routers configured such that the 117 LAN connects with
OpenVPN to my main LAN on 119 and the main LAN router has its routing set up to
channel traffic for 117 via the OpenVPN tunnel.

It works well for devices connected to the two LAN sections directly, but not
when a device is connected to the main LAN via OpenVPN while travelling.
In this case (I am now half a workld away from home) I can reach my home LAN
(119) but not the 117 LAN...

So now I wonder how I should set up the OpenVPN server on the main LAN such that
if a client wants to talk to a device on the 117 segment it can actually reach
it?

The server is set up for a split tunnel such that if a client addresses the
server side LAN it will route through the tunnel but for Internet traffic it
should use the local gateway directly.
Now I think that it is actually doing this for traffic to LAN segment 117 too
and this is what I would like to change.

Here is my server side conf file:

# this is the config for local only access
port 1190
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh2048.pem
tls-auth /etc/openvpn/keys/ta.key 0
topology subnet
server 10.8.139.0 255.255.255.0  'nopool'
ifconfig-pool 10.8.139.2 10.8.139.127 255.255.255.0
ifconfig-pool-persist ipplocal.txt
push "route 192.168.119.0 255.255.255.0" #Local LAN access
push "dhcp-option DNS 192.168.119.1" #Local server
push "dhcp-option DNS 208.67.220.220" #Public server
keepalive 10 120
cipher AES-256-CBC
#Disable compression and push this to the client
comp-lzo no
push "comp-lzo no"

# This is needed for site-to-site routing via remote Router
client-config-dir /etc/openvpn/ccdl
route 192.168.117.0 255.255.255.0
# Allow other clients to the server to also reach remote
client-to-client
push "route 192.168.117.0 255.255.255.0"
# end site-to-site routing
max-clients 20
persist-key
persist-tun
status /etc/openvpn/log/ovpn-status_local.log
log /etc/openvpn/log/ovpn_local.log
verb 4
mute 10
explicit-exit-notify 1
push "explicit-exit-notify 1"

It seems like the following line does not affect the connected VPN clients on
the server LAN:
route 192.168.117.0 255.255.255.0

What could I change to make it work?

Can this line be modified to encompass a larger subnet maybe?
push "route 192.168.119.0 255.255.255.0" #Local LAN access

for example 192.168.116.0/22 (covering 116, 117, 118, 119)


-- 
Bo Berglund
Developer in Sweden



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

2022-10-02 Thread David W Graham 
I've only been following this loosely, and may have missed the clear
statement. I apologise for that.

Windows 10 is inherently IPV6, and IPV4 is only bolted on. That has
occasional odd effects with routing (and with network timeouts and
discovery and other stuff), where the IPV4 follows an IPV6 state
instead of the expected result.

Have you tried all this with all IPV6 turned off at both ends?

On Fri, 30 Sept 2022 at 20:32, Sebastian Arcus  wrote:
>
>
> On 28/09/2022 18:37, Selva Nair wrote:
> > Hello,
> >
> > On Wed, Sep 28, 2022 at 1:10 PM Sebastian Arcus  > > wrote:
> >
> >
> > On 27/09/2022 21:09, tincantech wrote:
> > Some updates from today's testing:
> >
> > Test case 1
> >
> > Topology: subnet
> > Adapter: WinTUN
> > Netbios over TCP/IP: disabled or enabled
> > Result: 300kbs (for both states of NetBIOS over TCP/IP)
> >
> > Test case 2
> >
> > Topology: subnet
> > Adapter: TAP
> > Netbios over TCP/IP: disabled or enabled
> > Result: 900Mbs (for both states of Netbios over TCP/IP)
> >
> >
> > Essentially using "topology subnet" seems to work fine with the TAP
> > adapter, but routes all smb traffic through the tunnel with the WinTUN
> > adapter, even when Netbios over TCP/IP is disabled.
> >
> > I'm not sure if this actually clarifies things or makes it worse. I
> > re-run the tests several times, and rebooted the machine after changing
> > the settings on the adapters and before running the tests
> >
> >
> > This is getting more and more mysterious. Somehow SMB traffic is using
> > the VPN IP and hence getting routed through the tunnel. DNS/netbios
> > would have been the obvious culprit, but  that doesn't seem to be the
> > case... As Windows has no built-in policy routing facilities (does it?),
>
> Windows 10 has the NRPT table - which is policy based routing. I don't
> know if it is similar to what is available on other OS's though. I have
> already thought about it, as I had some dealings with it in the past. I
> checked the settings on the machine and the table is empty.
>
>
> > probably there is some third party port forwarding running on the
> > client?
>
> Seems unlikely - they are just bog standard office machines, and the
> users have no admin access to install software. But I guess anything is
> possible. Also the issue is present on both machines which have OpenVPN
> installed
>
> However, that should have affected both wintun and tap-windows
> > tunnels. Can you mount a shared folder using the LAN IP of the server
> > like \\192.168.112.xx and see whether that makes a difference?
>
> I can certainly try that, but I wonder if it would yield any useful
> information, since netstat shows during the file transfer that the
> client is definitely accessing Samba on the server at 192.168.112.1 and
> Samba on the server is configured to listen only to the loopback
> interface and 192.168.112.1, so any attempt to talk to it at
> 192.168.114.1 (the vpn interface) would be rejected
>
> But if you think the above would still be useful, I can certainly try it
>
> >
> > tcpdump could also help figure out why there are two smb streams one
> > using LAN IP and other using the VPN, which is carrying what traffic,
> > which one gets established first etc..
>
> I could do that. I'm not overly familiar with tcpdump. Would a command
> like below capture what is needed on the server side (assuming the vpn
> client is on 192.168.14.53 and 192.168.112.10)?
>
> tcpdump -n -w dump.file host 192.168.114.53 or 192.168.112.10 and tcp
> port 445
>
>
> ___
> Openvpn-users mailing list
> Openvpn-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users