Local Bridge to eth0 causing DHCP headache!

Post your questions about SoftEther VPN software here. Please answer questions if you can afford.
Post Reply
cmpts_cpeacock
Posts: 18
Joined: Sun Aug 05, 2018 11:38 am

Local Bridge to eth0 causing DHCP headache!

Post by cmpts_cpeacock » Wed Oct 02, 2019 5:50 pm

Hi,

I am using a local bridge. VPN clients connect fine and are issued an IP from dnsmasq DHCP.

However, for VPN clients to be able to connect to network devices attached to the eth0 network I need to create an additional local bridge to the hub, so hub -> eth0.

However, as dnsmasq is issuing IPs to VPN clients, with this local bridge between hub and eth0 the devices on the network connected to eth0 are also getting IPs from dnsmasq.

I've tried to edit the dnsmasq.conf file but it made no difference (I added an except and tried no-dhcp…)

Any suggestions?

Thanks

ozone
Posts: 65
Joined: Thu Sep 19, 2019 7:18 pm

Re: Local Bridge to eth0 causing DHCP headache!

Post by ozone » Wed Oct 02, 2019 10:04 pm

Yes, thanks to the bridge, both networks are receiving the same DHCP broadcasts.

Key is to separate those two areas, or let the DHCP from your main network (where eth0 is part of) also issue the VPN-ip's.
(or use DnsMasq for both)

You can separate the two the easiest way by using securenat, and remove the bridge again.
Traffic will then be ROUTED between eth0 and the vpn-clients, but also have NAT.

If you don't want that (extra) NAT, but just forwarding, I guess it should also be possible with SE's "layer3 switch settings".
But never tried that....
(or forward on host-OS level)

cmpts_cpeacock
Posts: 18
Joined: Sun Aug 05, 2018 11:38 am

Re: Local Bridge to eth0 causing DHCP headache!

Post by cmpts_cpeacock » Wed Oct 02, 2019 10:09 pm

Ah right!

But no way to prevent dnsmasq issuing IPs to anything other than to the tap interface only?

ozone
Posts: 65
Joined: Thu Sep 19, 2019 7:18 pm

Re: Local Bridge to eth0 causing DHCP headache!

Post by ozone » Wed Oct 02, 2019 10:59 pm

I don't think so, no....

Broadcasts are going out to "everybody who cares to listen". So when a client starts sending a DHCP request, both DHCP's would "hear it" and respond.
The fastest one will probably win. In this case it seems to be the DnsMasq server.
In theory it is possible to filter those packets out with bridge-filter rules, but a SE-bridge is, as far as I know, not set up to do so.

Maybe it is possible to block DHCP traffic already at the virtualhub, with "virtual hub extended options" (although I don't see it there).
But this would probably also mean that DnsMasq does not receive it. So NO-one of the VPNclients get an IP.

dsadmin
Posts: 7
Joined: Tue Oct 08, 2019 2:34 pm
Location: USA
Contact:

Re: Local Bridge to eth0 causing DHCP headache!

Post by dsadmin » Tue Oct 08, 2019 2:43 pm

You can use Access Lists, although not 100% sure how yet. I know then can be blocked (allow all other traffic you want then set the last rule to deny everything). I am still trying to figure out how to allow DHCP myself, reject client to client traffic and then only allow a specific traffic to the clients and back. Troubleshooting ACLs in the virtual hubs can be a pain. And before someone says anything I know about the HUB setting to isolate the clients but I am cascaded so that doesn't work, have to use ACLs.

ozone
Posts: 65
Joined: Thu Sep 19, 2019 7:18 pm

Re: Local Bridge to eth0 causing DHCP headache!

Post by ozone » Tue Oct 08, 2019 7:23 pm

Interesting idea ACL's, did not think of that....

And, you can do it at two different places too. (1- in the virtualhub under the "manage access lists", and 2- virtualhub->"virtual hub properties"->"ïp access control list")
The first seems to have the most options.

The problem however with dhcp is, that before the clients connects, the dhcp-server usually does not know either client-ip or -mac. (unless you use whitelists/reservations or similar)
That will make distinguishing between dhcp-requests from LAN and dhcp-request from VPN, a real challenge with ACL's.
----
That said, regarding the original question, it was brought to my attention that there may be a setting that allows only ONE dhcp server to respond: "UseHubNameAsDhcpUserClassOption" (under the virtualhub->"virtualhub properties"->"Edit virtualhub extended options list")
This will add the hub-name as the "userclass" option in the request, and give the DHCP server a way to separate vpn-clients from LAN-clients.

In theory, userclass can then be used to only-respond on the DnsMasq-dhcp, and ignore on the "lan" dhcp.

dsadmin
Posts: 7
Joined: Tue Oct 08, 2019 2:34 pm
Location: USA
Contact:

Re: Local Bridge to eth0 causing DHCP headache!

Post by dsadmin » Wed Oct 09, 2019 1:02 am

Yeah, I created a post about this and things I have tried, I just want to find the logs so I can test what is actually being blocked so I can allow it. I was hoping that no broadcast message would reach any client at all. Good point about the authoritative DHCP though.

As for ACL vs. IP Access Lists, they are distinctly different. They have a write about it, the IP Access Lists are allow/deny certain IPs from connecting to the Hub. ACL is mid-traffic ACL like a firewall.

ozone
Posts: 65
Joined: Thu Sep 19, 2019 7:18 pm

Re: Local Bridge to eth0 causing DHCP headache!

Post by ozone » Wed Oct 09, 2019 3:06 pm

I just want to find the logs so I can test what is actually being blocked so I can allow it.
The log files can be configured under the virtualhub in the servermanager gui.
And downloaded too, so that the actual location doesn't have to be known.
On my installs (debian) by default they are subfolders in the installation folder.

I just don't know if it is possible to actually create the logging-detail you try to achieve.
I was hoping that no broadcast message would reach any client at all.
Apart from the "dropBroadcastsInPrivacyFilterMode" option, I don't think that is possible.
At least I can't see any other option that hints to that.
As for ACL vs. IP Access Lists....
Thanks... was wondering why it was at 2 places...

I'll take a look at your other post too.

dsadmin
Posts: 7
Joined: Tue Oct 08, 2019 2:34 pm
Location: USA
Contact:

Re: Local Bridge to eth0 causing DHCP headache!

Post by dsadmin » Mon Sep 28, 2020 10:11 pm

I finally sat down and diagramed the requests and responses for DHCP.

I have three rules, one is specific to 0.0.0.0/32 and 255.255.255.255/32, the second rule is my DHCP server network range as the source and my network address at port 68 as destination and the last rule is my DHCP servers network range with a destination of 255.255.255.255/32. All traffic is UDP.

==== 1 ====
Memo: DHCP DISCOVER/REQUEST
Action: Pass
Source is 0.0.0.0/32
Destination is 255.255.255.255/32

Protocol Type is UDP/17

Source Port range is 68/68 and Destination Port range is 67/67

==== 2 ====
Memo: DHCP OFFER/ACK
Action: Pass
Source is DHCPServerNetwork/Mask (for example: 192.168.1.248/29, I have cluster routers with DHCP services)
Destination is NetworkAddress/Mask (for example: 192.168.1.0/24)

Protocol Type is UDP/17

Source Port range is 67/67 and Destination Port range is 68/68

==== 3 ====
Memo: DHCP OFFER/ACK BROADCAST
Action: Pass
Source is DHCPServerNetwork/Mask (for example: 192.168.1.248/29, I have cluster routers with DHCP services)
Destination is 255.255.255.255/32

Protocol Type is UDP/17

Source Port range is 67/67 and Destination Port range is 68/68

This will allow for your Bridge interface to pass DHCP and this is far more granular so others cannot become a DHCP on that subnet.

The reason for the DHCPServerNetwork/Mask is you might have a cluster/VRRP'd device or a pair of DHCP servers responding. If you have two individual DHCP servers, you can do a /30 and really narrow the scope.

merlinweb
Posts: 1
Joined: Tue Mar 23, 2021 1:27 pm

Re: Local Bridge to eth0 causing DHCP headache!

Post by merlinweb » Tue Mar 23, 2021 1:32 pm

Thanks a lot for these ACLs, you could solve me a big trouble in my lan....

I'm trying it now...
I have only one VPN DHCP server on 192.168.30.0 network, so I guess
DHCPServerNetwork/Mask 192.168.30.1/32
NetworkAddress/Mask 192.168.30.0/24

Sorry my poor knowledge, but I don't understand why in first rule port ranges are inverted

I will let you know if dhcp broadcast will be blocked on eth0

Cheers

Merlinweb

Post Reply