Re: [Openvpn-users] site-to-site bridged setup | clients are missing default route
Hi Lorenz, On 07/08/19 21:35, Lorenz wrote: Huge thanks to both of you! I really appreciate you trying to help me. On 8/6/19 5:59 PM, Jan Just Keijser wrote: as you stated: your bridged setup is working, and your clients in network B get their DHCP addresses from the server in network A. The only thing missing is the default route for these clients. That means it's the DHCP server in network A that is not pushing the right default gateway to these clients. Which DHCP server software are you using? For standard dhcpd, you'd add something like I did not think of the DHCP server because if a computer of network B was physically moved into network A it did get the right gateway information and therefore added a default route. So I do not think it is the DHCP server's fault. I still suspect the dhcp server, or the parsing of the options that the dhcp server is handing out to clients in network B; when you have a fully bridged setup then both networks are 99.9% connected at the L2 (ethernet) level. Handing out IP addresses and default routes is then not up to OpenVPN, but to the network layer above: in your case, your DHCP server. However, it is possible that clients in network B refuse to add the default route offered by the DHCP server because they cannot find the MAC address of the gateway. I'd run something like wireshark/tcpdump on your network (e.g. on the openvpn client) and then watch the entire DHCP message exchange to see if the right default route is offered. If it is, I'd then investigate why the client (i.e a machine in network B) is not applying this default route. If the DHCP server is *not* offering the right default route for clients in network B, then you need to investigate the dhcp server settings to see why it does not do so. HTH, JJK ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] site-to-site bridged setup | clients are missing default route
Huge thanks to both of you! I really appreciate you trying to help me. On 8/6/19 5:59 PM, Jan Just Keijser wrote: as you stated: your bridged setup is working, and your clients in network B get their DHCP addresses from the server in network A. The only thing missing is the default route for these clients. That means it's the DHCP server in network A that is not pushing the right default gateway to these clients. Which DHCP server software are you using? For standard dhcpd, you'd add something like I did not think of the DHCP server because if a computer of network B was physically moved into network A it did get the right gateway information and therefore added a default route. So I do not think it is the DHCP server's fault. On 8/7/19 6:27 AM, Alex K wrote: I understand that you have one server and one client. Then at eth1 of client you have several computers. I would avoid using the term client for these computers since they are not vpn clients but just devices on network B connected at eth1 of client. This will avoid confusion. You are right. My labeling was kind of confusing. I am sorry for that. On 8/7/19 6:27 AM, Alex K wrote: I suspect that pcs at network B are not able to add default gw pushed from DHCP of A since that gw is not known to them (does not belong at network B). For computers at net B to reach internet through A it is enough to have redirect-gateway def1 for the client. This will force all traffic from client to go through the tunnel. In case computers are still not able to reach Internet through A then I would check NAT, firewall, routing at client. I tried adding redirect-gateway def1 to the clients configuration, which indeed modifies the clients rules to push all outgoing traffic through the tunnel. This however did not change anything on the other computers of network B. After a lot of trial and error I figured it out. Even though I do not quite get it why this is working. The server configuration did contain the server-bridge directive without any additional parameters. The OpenVPN documentation [1] states: In another example, *–server-bridge* (without parameters) expands as follows: *mode server tls-server push "route-gateway dhcp" * This means adding the directive without any parameters implies pushing route-gateway dhcp. The documentation also continues: Or *–server-bridge nogw* expands as follows: *mode server tls-server * So by adding nogw the route-gateway dhcp directive is not pushed. Adding *server-bridge nogw* *push "route-gateway arbitrary-ip-within-network-A"* instead of *server-bridged* solved the problem of the missing default route on computers in network B*.* This seems really weird, because I can specify any ip address within network A and it will work.**It does not have to be the gateway/router or the server. But the ip has to be within A's subnet. The route-gateway directive does not add or delete any routes on the client. So why then is this directive critical but still can contain any ip address within network A? Can anyone of you explain this behavior? Thank you so much for your help! Best Lorenz [1] https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] site-to-site bridged setup | clients are missing default route
On Sun, Aug 4, 2019, 23:34 Lorenz wrote: > Hey there, > > I'm trying to connect two networks using a bridged OpenVPN (site to > site) setup. > The OpenVPN server is located within network A and the OpenVPN client in > network B. Both networks are connected to the internet via a router. > Network A and network B do use different subnets. > The goal is to "move" all clients of network B (which are connected to > server 2's eth1) into network A. All clients of network B should think > they are actually in network A. They should get their DHCP leases from > the router of network A, be able to communicate with every client within > network A, and their internet traffic should look like it has originated > from network A. > > The machine which is running the OpenVPN server has only one network > interface. The OpenVPN client, on the other hand, has two, one connected > to the router and the other one to all the clients. > > Bridging the tap adapter and the network interface on the OpenVPN server > machine works as expected. On the OpenVPN client's machine, I'm using > the same up script as on the server with minor modifications to bridge > the tap adapter with eth1. > Everything seems to work. Clients of network B do get DHCP leases from > the router of network A and can communicate with all clients located in > network B. > But there is one tiny problem: All the clients of network B do not add > any default routes. When manually adding a default route on the clients > of network B through the router of network a (ip route add default via > router-a-address-here), the setup works as it should. Clients of network > B then can reach the internet through network A. > I understand that you have one server and one client. Then at eth1 of client you have several computers. I would avoid using the term client for these computers since they are not vpn clients but just devices on network B connected at eth1 of client. This will avoid confusion. I suspect that pcs at network B are not able to add default gw pushed from DHCP of A since that gw is not known to them (does not belong at network B). For computers at net B to reach internet through A it is enough to have redirect-gateway def1 for the client. This will force all traffic from client to go through the tunnel. In case computers are still not able to reach Internet through A then I would check NAT, firewall, routing at client. > > > The OpenVPN guide for ethernet bridging [1] mentions some iptable rules, > which I do not think are necessary, because they did not make any > difference. > The up and down scripts used by me originate from [2]. > > All machines run Debian Buster. > > I do know the directive "redirect-gateway def1" can be used to add a > default route to the OpenVPN client's machine, but this does not affect > the remaining clients of network B. > > Do you know why all clients of network B do get DHCP leases of network A > but do not add any default routes? Shouldn't they automatically add > default routes when getting DHCP leases? > > > Thank you for your help! > > > Best > Lorenz > > [1] > > https://openvpn.net/community-resources/ethernet-bridging/#bridge-server-on-linux > [2] https://wiki.archlinux.org/index.php/OpenVPN_Bridge > > > > >Network A Network B > > -- -- -- > -- -- > |Sever 1 | | Router | INTERNET > | Router | eth0 |Server 2| eth1 --- > | Client | > | OpenVPN Server | | -- -- | > OpenVPN Client | | -- > -- | -- | > | | -- > -- | |--- | Client | > | Client | | | -- > -- | | > | | -- > -- | | | Client | > | Client | | | -- > -- | | > > ... ... > > ___ > 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
Re: [Openvpn-users] site-to-site bridged setup | clients are missing default route
Hi Lorenz, On 04/08/19 22:39, Lorenz wrote: The network setup got scrambled in my previous email, so I made a screenshot and attached it. as you stated: your bridged setup is working, and your clients in network B get their DHCP addresses from the server in network A. The only thing missing is the default route for these clients. That means it's the DHCP server in network A that is not pushing the right default gateway to these clients. Which DHCP server software are you using? For standard dhcpd, you'd add something like # option routers is the same as the default gateway option routers 10.129.36.1; (Default Gateway/Router for loading software) option subnet-mask 255.255.255.0; (Default Gateway/Router Subnet Mask) HTH, JJK On 8/4/19 10:15 PM, Lorenz wrote: Hey there, I'm trying to connect two networks using a bridged OpenVPN (site to site) setup. The OpenVPN server is located within network A and the OpenVPN client in network B. Both networks are connected to the internet via a router. Network A and network B do use different subnets. The goal is to "move" all clients of network B (which are connected to server 2's eth1) into network A. All clients of network B should think they are actually in network A. They should get their DHCP leases from the router of network A, be able to communicate with every client within network A, and their internet traffic should look like it has originated from network A. The machine which is running the OpenVPN server has only one network interface. The OpenVPN client, on the other hand, has two, one connected to the router and the other one to all the clients. Bridging the tap adapter and the network interface on the OpenVPN server machine works as expected. On the OpenVPN client's machine, I'm using the same up script as on the server with minor modifications to bridge the tap adapter with eth1. Everything seems to work. Clients of network B do get DHCP leases from the router of network A and can communicate with all clients located in network B. But there is one tiny problem: All the clients of network B do not add any default routes. When manually adding a default route on the clients of network B through the router of network a (ip route add default via router-a-address-here), the setup works as it should. Clients of network B then can reach the internet through network A. The OpenVPN guide for ethernet bridging [1] mentions some iptable rules, which I do not think are necessary, because they did not make any difference. The up and down scripts used by me originate from [2]. All machines run Debian Buster. I do know the directive "redirect-gateway def1" can be used to add a default route to the OpenVPN client's machine, but this does not affect the remaining clients of network B. Do you know why all clients of network B do get DHCP leases of network A but do not add any default routes? Shouldn't they automatically add default routes when getting DHCP leases? Thank you for your help! Best Lorenz [1] https://openvpn.net/community-resources/ethernet-bridging/#bridge-server-on-linux [2] https://wiki.archlinux.org/index.php/OpenVPN_Bridge Network A Network B -- -- -- -- -- | Sever 1 | | Router | INTERNET | Router | eth0 | Server 2 | eth1 --- | Client | | OpenVPN Server | | -- -- | OpenVPN Client | | -- -- | -- | | | -- -- | |--- | Client | | Client | | | -- -- | | | | -- -- | | | Client | | Client | | | -- -- | | ... ... ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] site-to-site bridged setup | clients are missing default route
The network setup got scrambled in my previous email, so I made a screenshot and attached it. Best Lorenz On 8/4/19 10:15 PM, Lorenz wrote: Hey there, I'm trying to connect two networks using a bridged OpenVPN (site to site) setup. The OpenVPN server is located within network A and the OpenVPN client in network B. Both networks are connected to the internet via a router. Network A and network B do use different subnets. The goal is to "move" all clients of network B (which are connected to server 2's eth1) into network A. All clients of network B should think they are actually in network A. They should get their DHCP leases from the router of network A, be able to communicate with every client within network A, and their internet traffic should look like it has originated from network A. The machine which is running the OpenVPN server has only one network interface. The OpenVPN client, on the other hand, has two, one connected to the router and the other one to all the clients. Bridging the tap adapter and the network interface on the OpenVPN server machine works as expected. On the OpenVPN client's machine, I'm using the same up script as on the server with minor modifications to bridge the tap adapter with eth1. Everything seems to work. Clients of network B do get DHCP leases from the router of network A and can communicate with all clients located in network B. But there is one tiny problem: All the clients of network B do not add any default routes. When manually adding a default route on the clients of network B through the router of network a (ip route add default via router-a-address-here), the setup works as it should. Clients of network B then can reach the internet through network A. The OpenVPN guide for ethernet bridging [1] mentions some iptable rules, which I do not think are necessary, because they did not make any difference. The up and down scripts used by me originate from [2]. All machines run Debian Buster. I do know the directive "redirect-gateway def1" can be used to add a default route to the OpenVPN client's machine, but this does not affect the remaining clients of network B. Do you know why all clients of network B do get DHCP leases of network A but do not add any default routes? Shouldn't they automatically add default routes when getting DHCP leases? Thank you for your help! Best Lorenz [1] https://openvpn.net/community-resources/ethernet-bridging/#bridge-server-on-linux [2] https://wiki.archlinux.org/index.php/OpenVPN_Bridge Network A Network B -- -- -- -- -- | Sever 1 | | Router | INTERNET | Router | eth0 | Server 2 | eth1 --- | Client | | OpenVPN Server | | -- -- | OpenVPN Client | | -- -- | -- | | | -- -- | |--- | Client | | Client | | | -- -- | | | | -- -- | | | Client | | Client | | | -- -- | | ... ... ___ 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
