Page 1 of 1

Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Fri May 30, 2025 5:36 pm
by chrisw
Hi, long time lurker, first time poster. We've been using SE 4.x (OpenVPN clone) for a few years now in SecureNAT mode on a Hyper-V VM. Recently, I've decided to de-couple SE from Hyper-V and running on a standalone Debian Linux machine (bare metal.) Moving the configuration over was super easy via the VPN Manager. So far so good.

One issue we've had is that we cannot see who's accessing the VPN unless accessing the VPN manager. So, a decision was made to utilize the local bridging option of SE and have clients acquire an IP address from on-premises DHCP server and we're ALMOST there. The problem we're running into is that the client is not receiving an IP address from the DHCP server but from SecureNAT which is disabled.

I've read dozens of posts on this forum thinking I could find the answer, but nothing has gained any traction and I'm aware of my limitations and know when to ask for help.

Here's what I've done:

- installed Debian 12.11 x64
- installed SE 5.x via apt, migrated configuration via VPN Manager running on another machine (I also manually compiled 4.x and tried it as well, same results)
- created a separate VLAN for the VPN connection, in this case, VLAN id=99 with accompanying DHCP server servicing it. This works fine when plugged into a switch port designated for that VLAN, I get an IP address. When a client connects, it gets assigned a 192.168.30.x address from SE even though Virtual NAT and Virtual DHCP is disabled.
- IP forwarding is enabled via systctl (net.ipv4.ip_forward = 1)

My config:

My test workstation: 10.220.40.146 (VLAN id=40)
Server: 10.220.20.127 (enp1s0) - fully configured; IP, DNS, GW, etc via DHCP. Switch port is VLAN id=20 (Servers)
Bridge Interface: No IP settings (enp4s0) and administratively up. Not a TAP device but physical NIC. Switch port is VLAN id=99 (VPN)
DHCP is not coming from Windows DHCP server in VLAN20 but rather the router itself (which uses a relay for all VLANs, except 99 which it handles itself for simplicity's sake in testing.)

Code: Select all

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 40:62:31:0a:0a:d7 brd ff:ff:ff:ff:ff:ff
    inet 10.220.20.127/24 brd 10.220.20.255 scope global dynamic enp1s0
       valid_lft 2923sec preferred_lft 2923sec
    inet6 fe80::4262:31ff:fe0a:ad7/64 scope link
       valid_lft forever preferred_lft forever

5: enp4s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 40:62:31:0a:0a:da brd ff:ff:ff:ff:ff:ff
    inet6 fe80::4262:31ff:fe0a:ada/64 scope link
       valid_lft forever preferred_lft forever
Here's what's in the server log when a client connects:

Code: Select all

2025-05-30 11:07:37.418 OpenVPN Session 4 (10.220.40.156:53987 -> 10.220.20.127:1195) Channel 0: Option Strings Received: "V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client"
2025-05-30 11:07:37.418 OpenVPN Session 4 (10.220.40.156:53987 -> 10.220.20.127:1195) Channel 0: Client certificate received (subject: CN="vpn229525752.softether.net"), will use certificate authentication.
2025-05-30 11:07:37.418 OpenVPN Session 4 (10.220.40.156:53987 -> 10.220.20.127:1195) Channel 0: Option Strings to Send: "V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server"
2025-05-30 11:07:37.428 On the TCP Listener (Port 0), a Client (IP address 10.220.40.156, Host name "DESKTOP-SEVFLVJ.hostname.com", Port number 53987) has connected.
2025-05-30 11:07:37.428 For the client (IP address: 10.220.40.156, host name: "DESKTOP-SEVFLVJ.hostname.com", port number: 53987), connection "CID-6" has been created.
2025-05-30 11:07:37.428 SSL communication for connection "CID-6" has been started. The encryption algorithm name is "(null)".
2025-05-30 11:07:37.428 [HUB "VPN"] The connection "CID-6" (IP address: 10.220.40.156, Host name: DESKTOP-SEVFLVJ.hostname.com, Port number: 53987, Client name: "OpenVPN Client", Version: 4.44, Build: 9807) is attempting to connect to the Virtual Hub. The auth type provided is "External server authentication" and the user name is "vpnusername".
2025-05-30 11:07:37.449 [HUB "VPN"] Connection "CID-6": Successfully authenticated as user "vpnusername".
2025-05-30 11:07:37.449 [HUB "VPN"] Connection "CID-6": The new session "SID-vpnusername-[OPENVPN_L3]-3" has been created. (IP address: 10.220.40.156, Port number: 53987, Physical underlying protocol: "Legacy VPN - OPENVPN_L3")
2025-05-30 11:07:37.449 [HUB "VPN"] Session "SID-vpnusername-[OPENVPN_L3]-3": The parameter has been set. Max number of TCP connections: 1, Use of encryption: Yes, Use of compression: No, Use of Half duplex communication: No, Timeout: 20 seconds.
2025-05-30 11:07:37.449 [HUB "VPN"] Session "SID-vpnusername-[OPENVPN_L3]-3": VPN Client details: (Client product name: "OpenVPN Client", Client version: 444, Client build number: 9807, Server product name: "SoftEther VPN Server (64 bit)", Server version: 444, Server build number: 9807, Client OS name: "OpenVPN Client", Client OS version: "-", Client product ID: "-", Client host name: "", Client IP address: "10.220.40.156", Client port number: 53987, Server host name: "10.220.20.127", Server IP address: "10.220.20.127", Server port number: 1195, Proxy host name: "", Proxy IP address: "0.0.0.0", Proxy port number: 0, Virtual Hub name: "VPN", Client unique ID: "17113951FB618098CFFE48A71BAF7D75")
2025-05-30 11:07:37.499 [HUB "VPN"] Session "SID-LOCALBRIDGE-1": The DHCP server of host "5E-AD-A8-E7-79-1B" (192.168.30.1) on this session allocated, for host "SID-vpnusername-[OPENVPN_L3]-3" on another session "CA-15-F2-CA-34-BE", the new IP address 192.168.30.109.
2025-05-30 11:07:37.499 OpenVPN Session 4 (10.220.40.156:53987 -> 10.220.20.127:1195) Channel 0: The channel becomes the established state.
2025-05-30 11:07:37.499 OpenVPN Session 4 (10.220.40.156:53987 -> 10.220.20.127:1195) Channel 0: The IP address and other network information parameters are set successfully. IP Address of Client: 192.168.30.109, Subnet Mask: 255.255.255.0, Default Gateway: 192.168.30.1, DNS Server 1: 10.220.50.165, DNS Server 2: 10.220.50.174, WINS Server 1: , WINS Server 2:
2025-05-30 11:07:37.499 OpenVPN Session 4 (10.220.40.156:53987 -> 10.220.20.127:1195) Channel 0: The full strings replied: "PUSH_REPLY,ping 3,ping-restart 10,ifconfig 192.168.30.109 192.168.30.110,dhcp-option DOMAIN hostname.com,dhcp-option DNS 10.220.50.165,dhcp-option DNS 10.220.50.174,route-gateway 192.168.30.110,redirect-gateway def1"
2025-05-30 11:07:54.708 [HUB "VPN"] Session "SID-vpnusername-[OPENVPN_L3]-3": The session has been terminated. The statistical information is as follows: Total outgoing data size: 22921 bytes, Total incoming data size: 4650 bytes.
2025-05-30 11:07:54.739 Connection "CID-6" terminated by the cause "The VPN session has been deleted. It is possible that either the administrator disconnected the session or the connection from the client to the VPN Server has been disconnected." (code 11).
2025-05-30 11:07:54.739 Connection "CID-6" has been terminated.
2025-05-30 11:07:54.739 The connection with the client (IP address 10.220.40.156, Port number 53987) has been disconnected.
When a client connects, I see the following from the DHCP server:

Code: Select all

2025-05-30T10:32:40-06:00 ROUTER dnsmasq-dhcp[1928187]: DHCPDISCOVER(br99) 192.168.30.109 ca:15:f2:ca:34:be
2025-05-30T10:32:40-06:00 ROUTER dnsmasq-dhcp[1928187]: DHCPOFFER(br99) 10.220.99.126 ca:15:f2:ca:34:be
2025-05-30T10:32:40-06:00 ROUTER dnsmasq-dhcp[1928187]: DHCPREQUEST(br99) 192.168.30.109 ca:15:f2:ca:34:be
2025-05-30T10:32:40-06:00 ROUTER dnsmasq-dhcp[1928187]: DHCPNAK(br99) 192.168.30.109 ca:15:f2:ca:34:be wrong server-ID
Some useful information:

ca:15:f2:ca:34:be is my test workstation MAC address via OpenVPN/SE (it's assigned, not physical address)
5E-AD-A8-E7-79-1B is the MAC address in the Virtual DHCP/NAT settings, even though both are disabled (unticked) which can be verified in the vpn_server.config (below) -- I even tried changing the Virtual DHCP addressing to ensure that 192.168.30.x was not present in the config in any way so I mirrored my DHCP range/config from the ROUTER (made no difference.)

Code: Select all

                        declare SecureNAT
                        {
                                bool Disabled true
                                bool SaveLog true

                                declare VirtualDhcpServer
                                {
                                        string DhcpDnsServerAddress 10.220.50.165
                                        string DhcpDnsServerAddress2 10.220.50.174
                                        string DhcpDomainName hostname.com
                                        bool DhcpEnabled false
                                        uint DhcpExpireTimeSpan 7200
                                        string DhcpGatewayAddress 10.220.99.1
                                        string DhcpLeaseIPEnd 10.220.99.200
                                        string DhcpLeaseIPStart 10.220.99.100
                                        string DhcpPushRoutes $
                                        string DhcpSubnetMask 255.255.255.0
                                }
                                declare VirtualHost
                                {
                                        string VirtualHostIp 10.220.99.254
                                        string VirtualHostIpSubnetMask 255.255.255.0
                                        string VirtualHostMacAddress 5E-AD-A8-E7-79-1B
                                }
                                declare VirtualRouter
                                {
                                        bool NatEnabled false
                                        uint NatMtu 1500
                                        uint NatTcpTimeout 1800
                                        uint NatUdpTimeout 60
                                }
                        }
 
I can also see the DHCP server on the ROUTER attempting to assign the following MAC address an IP which is not connected to the VLAN in any way. Since it appears to be a random MAC address, not sure where it's coming from as it appears neither on my ROUTER or the SE linux machine and there are no other clients connected to this VLAN:

Code: Select all

2025-05-30T11:18:55-06:00 ROUTER dnsmasq-dhcp[1928187]: DHCPDISCOVER(br99) da:12:5e:36:a6:35
2025-05-30T11:18:55-06:00 ROUTER dnsmasq-dhcp[1928187]: DHCPOFFER(br99) 10.220.99.109 da:12:5e:36:a6:35
2025-05-30T11:18:57-06:00 ROUTER dnsmasq-dhcp[1928187]: DHCPDISCOVER(br99) da:12:5e:36:a6:35
2025-05-30T11:18:57-06:00 ROUTER dnsmasq-dhcp[1928187]: DHCPOFFER(br99) 10.220.99.109 da:12:5e:36:a6:35
I also tried disabling SecureNAT kernel and Raw IP mode (saw in another post) but that didn't change anything. Also, when I go into the VPN HUB->Manage Sessions->MAC Address Table, I can see various MACs and their associated VLANs which tells me that I must have the bridge interface connected and configured correctly. However, when I look at VPN HUB->Manage Sessions->IP Address Table, I see 10.220.99.1 (my VLAN 99 gateway, which I'd expect to see) AND 192.168.30.1 which was the stock Virtual DHCP gateway setting, again, which is disabled.

I feel I'm almost there but just missing something. If there's any more information I can provide, please let me know!

Appreciate any help in advance.

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Sat May 31, 2025 2:28 am
by solo
Hello, you have two options.

#1 - go L2/TAP mode, and don't worry that "TAP mode is not supported in OpenVPN3" because " OpenVPN2 is here and it will stay. It supports bridging and will continue to do so. I advise that you use that. It is not 'old'. The last update it got was like 2 weeks ago." - https://forums.openvpn.net/viewtopic.php?t=34863

#2 - stay on L3/TUN mode and "reserve and each Virtual MAC address" https://www.softether.org/5-download/history
however due to a SE v4 bug, use v5 viewtopic.php?f=7&t=69678#p103587

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Sat May 31, 2025 1:38 pm
by chrisw
Hello @solo, thanks for responding.

When I got home last night I realized that I may be the cause of this issue and will attempt again on Monday when I'm back in the office.

What I think is happening is that I'm still running my "production" SE 4.x in the Hyper-V VM and SE 5.x on the Debian bare-metal machine within the same infrastructure but a misconfiguration of 4.x may be the cause. I think it's bleeding over to my 5.x installation so I'll shut that down on Monday and begin testing anew. The 4.x installation IS using SecureNAT Virtual NAT/DHCP and I think my test client is gaining an IP from there (came to me on the drive home and I'll check the 4.x install during testing to see if my test client is listed there with the IP "assigned" by my 5.x installation.)

Some additional details:

- The Debian install is running SE 5.01; the Hyper-V VM install is running 4.x (whatever is latest to download) and is using 192.160.30.x/24 for DHCP
- We use OpenVPN Connect 3.x in TUN mode as our users are all Windows 10/11 users.
- I'm fairly certain my 4.x VM is not configured correctly as I tried bridge-mode on it while running SecureNAT only to find out there's a problem with SET vSwitch using SRIOV and MAC Spoofing (part of the reason for the Hyper-V decoupling of SE to standalone---several other benefits as well.)

Since I can see the DHCP server offering 10.220.99.x to the client from the 5.x installation, I think the running SE 4.x is interfering, basically.

I'll try again on Monday and post back my findings.

Really appreciate you weighing in.

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Sat May 31, 2025 1:48 pm
by solo
No, none of it is relevant. Pick one of the two options and implement it.

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Mon Jun 02, 2025 4:43 pm
by chrisw
Well, looks like I was on the money with this.

My SE 4.x installation was using a local-bridge (vlan99) with SecureNAT (which isn't right, now I know--it's just pure SecureNAT now) and was picking up the assignment as my client connecting to my SE 5.x installation was showing up in the IP address list on the SE 4.x installation, not the 5.x installation. Removed the local-bridge on the SE 4.x VM and magically my 5.x installation was handing out DHCP assignments from my DHCP server. They are operating side-by-side in the same infrastructure with the intent to phase out the SE 4.x VM with the SE 5.x Linux installation.

Pretty happy with the result, just need to test some more.

Code: Select all

2025-06-02 09:59:43.664 [OpenVPN] 10.220.40.156:54367 -> 0.0.0.0:1195 (UDP): Session created.
2025-06-02 09:59:43.664 OpenVPN Session 1 (10.220.40.156:54367 -> 0.0.0.0:1195) Channel 0: A new channel is created.
2025-06-02 09:59:43.705 OpenVPN Session 1 (10.220.40.156:54367 -> 0.0.0.0:1195) Channel 0: Option Strings Received: "V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client"
2025-06-02 09:59:43.705 OpenVPN Session 1 (10.220.40.156:54367 -> 0.0.0.0:1195) Channel 0: Client certificate received (subject: CN="vpnddns.softether.net"), will use certificate authentication.
2025-06-02 09:59:43.705 OpenVPN Session 1 (10.220.40.156:54367 -> 0.0.0.0:1195) Channel 0: Option Strings to Send: "V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server"
2025-06-02 09:59:43.715 On the TCP Listener (Port 0), a Client (IP address 10.220.40.156, Host name "DESKTOP-SEVFLVJ.hostname.com", Port number 54367) has connected.
2025-06-02 09:59:43.715 For the client (IP address: 10.220.40.156, host name: "DESKTOP-SEVFLVJ.hostname.com", port number: 54367), connection "CID-4" has been created.
2025-06-02 09:59:43.725 SSL communication for connection "CID-4" has been started. The encryption algorithm name is "(null)".
2025-06-02 09:59:43.725 [HUB "VPN"] The connection "CID-4" (IP address: 10.220.40.156, Host name: DESKTOP-SEVFLVJ.hostname.com, Port number: 54367, Client name: "OpenVPN Client", Version: 5.01, Build: 9674) is attempting to connect to the Virtual Hub. The auth type provided is "External server authentication" and the user name is "vpnusername".
2025-06-02 09:59:43.735 [HUB "VPN"] Connection "CID-4": Successfully authenticated as user "vpnusername".
2025-06-02 09:59:43.735 [HUB "VPN"] Connection "CID-4": The new session "SID-vpnusername-[OPENVPN_L3]-3" has been created. (IP address: 10.220.40.156, Port number: 54367, Physical underlying protocol: "Legacy VPN - OPENVPN_L3")
2025-06-02 09:59:43.735 [HUB "VPN"] Session "SID-vpnusername-[OPENVPN_L3]-3": The parameter has been set. Max number of TCP connections: 1, Use of encryption: Yes, Use of compression: No, Use of Half duplex communication: No, Timeout: 20 seconds.
2025-06-02 09:59:43.735 [HUB "VPN"] Session "SID-vpnusername-[OPENVPN_L3]-3": VPN Client details: (Client product name: "OpenVPN Client", Client version: 501, Client build number: 9674, Server product name: "SoftEther VPN Server Developer Edition (64 bit) (Open Source)", Server version: 501, Server build number: 9674, Client OS name: "OpenVPN Client", Client OS version: "-", Client product ID: "-", Client host name: "", Client IP address: "10.220.40.156", Client port number: 54367, Server host name: "0.0.0.0", Server IP address: "0.0.0.0", Server port number: 1195, Proxy host name: "", Proxy IP address: "0.0.0.0", Proxy port number: 0, Virtual Hub name: "VPN", Client unique ID: "3C0BD2AEFE5EDAA2A1B52202426E006B")
2025-06-02 09:59:44.365 [HUB "VPN"] Session "SID-LOCALBRIDGE-1": The DHCP server of host "E4-38-83-36-89-21" (10.220.99.1) on this session allocated, for host "SID-vpnusername-[OPENVPN_L3]-3" on another session "CA-15-F2-CA-34-BB", the new IP address 10.220.99.123.
2025-06-02 09:59:44.365 OpenVPN Session 1 (10.220.40.156:54367 -> 0.0.0.0:1195) Channel 0: The channel becomes the established state.
2025-06-02 09:59:44.365 OpenVPN Session 1 (10.220.40.156:54367 -> 0.0.0.0:1195) Channel 0: The IP address and other network information parameters are set successfully. IP Address of Client: 10.220.99.123, Subnet Mask: 255.255.255.0, Default Gateway: 10.220.99.1, DNS Server 1: 10.220.99.1, DNS Server 2: , WINS Server 1: , WINS Server 2:
2025-06-02 09:59:44.365 OpenVPN Session 1 (10.220.40.156:54367 -> 0.0.0.0:1195) Channel 0: The full strings replied: "PUSH_REPLY,ping 3,ping-restart 10,topology subnet,ifconfig 10.220.99.123 255.255.255.0,dhcp-option DNS 10.220.99.1,route-gateway 10.220.99.1,redirect-gateway def1,block-outside-dns"
2025-06-02 09:59:59.558 [OpenVPN] 10.220.40.156:54366 -> 0.0.0.0:1195 (UDP): Session deleted.
2025-06-02 10:02:29.729 [HUB "VPN"] Session "SID-vpnusername-[OPENVPN_L3]-3": The session has been terminated. The statistical information is as follows: Total outgoing data size: 52364993 bytes, Total incoming data size: 5545927 bytes.
2025-06-02 10:02:29.759 Connection "CID-4" terminated by the cause "The VPN session has been deleted. It is possible that either the administrator disconnected the session or the connection from the client to the VPN Server has been disconnected." (code 11).
2025-06-02 10:02:29.759 Connection "CID-4" has been terminated.

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Tue Jun 03, 2025 12:10 am
by solo
Let's backtrack to your original objective.
chrisw wrote:
Fri May 30, 2025 5:36 pm
One issue we've had is that we cannot see who's accessing the VPN unless accessing the VPN manager.
Are you sure you can tell now who's on this random MAC? ---> "session "CA-15-F2-CA-34-BB", the new IP address 10.220.99.123"

Answer: except for the reshuffling of a few network components, nothing has changed.

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Tue Jun 03, 2025 3:32 am
by chrisw
Indeed - SCOM to the rescue; only had to modify my existing rule alert slightly (adding the MAC+IP, see below) which procures data from SE server log which allows me to look back in time if necessary.

The biggest driver for me was de-coupling SE from Hyper-V and having the nicety of seeing VPN connections from the main network management view. Unfortunately I cannot post an image from the network management view. I also leverage RADIUS authentication with SE which is tied to AD and only members of specific groups can connect to the VPN, so in my case, it works well for me.

Code: Select all

Connected: 2025-06-02 16:49:02
Username: vpnusername
IP Address: x.x.x.x
VPN IP Address: 10.220.99.123
MAC: CA-15-F2-CA-34-BB

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Tue Jun 03, 2025 7:02 pm
by chrisw
I guess the next nice-to-have would be is it possible to have LAN clients be able to reach VPN clients? I'm looking specifically one VLAN (20) able to reach the VPN clients (VLAN99) -- I've tried routing, tried the double-bridge scenario, tried the iptables POSTROUTING option but can't get the packets to flow into the VPN from the VLAN I want. I did read that Windows machines will not accept ICMP from subnets that it's not on (verified) so how else can I test this? My intent is to be able to have VLAN 20 (where my patch management machine lives) be able to directly interact with VPN clients rather than having VPN clients connect to the server whenever polling happens.

From the VPN client I can reach every single VLAN I have, including the SE server, without any issues.

Most of the tests I did were from posts here, but none worked in my case.

Layout (currently)

enp1s0 - 10.220.20.127 (VLAN20) - cable is plugged into switchport with VLAN20 as the default network.
enp4s0 - local bridge with hub "VPN" on VLAN99; clients are assigned 10.220.99.x addresses successfully. Cable is plugged into switchport with VLAN99 as the default network.

(this device has 4 physical NICs)

Can ping 10.220.20.127 and any other host in VLAN20 once connected but cannot ping 10.220.99.x from any hosts within VLAN20 including 10.220.20.127 which runs SE. I also installed a port scanning tool on one of the VLAN 20 hosts to work around the ICMP issue noted above. Traceroute from VLAN 20 to VLAN 99 falls over at VLAN 20's gateway. There is no firewall in place blocking this traffic.

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Wed Jun 04, 2025 8:07 am
by solo
"I did read that Windows machines will not accept ICMP from subnets that it's not on (verified)"
It's not true, expand the "scope" of remote address in the "File and Printer Sharing Echo Request ICMPv4-In" rule.
"cannot ping 10.220.99.x from any hosts within VLAN20 including 10.220.20.127 which runs SE"
It has nothing to do with SoftEther/VPN (nor this forum), it's just a routing issue. How's the parsing of random MACs in SE log going? The #2 option's virtual MAC address reservation is a really neat solution with static MACs.

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Wed Jun 04, 2025 11:34 am
by chrisw
solo wrote:
Wed Jun 04, 2025 8:07 am
"I did read that Windows machines will not accept ICMP from subnets that it's not on (verified)"
It's not true, expand the "scope" of remote address in the "File and Printer Sharing Echo Request ICMPv4-In" rule.
"cannot ping 10.220.99.x from any hosts within VLAN20 including 10.220.20.127 which runs SE"
Morning Solo, forgive my run-on sentences, first coffee and all :)

It has nothing to do with SoftEther/VPN (nor this forum), it's just a routing issue. How's the parsing of random MACs in SE log going? The #2 option's virtual MAC address reservation is a really neat solution with static MACs.
I didn't try expanding the scope as I was already in private network but I'll take another look. As for the nice-to-have, I know it's routing of some kind, just not sure where it falls over or where else to try. As far parsing the SE logs, SCOM does that for me and I was using it in Hyper-V (SCOM agent parses the server logs via regex) and works well. Reservations would work well in a lot of use-cases but not mine as I have a limited number of VPN users.

Ultimately, I think going to have to abandon this local-bridge idea because I discovered last night remotely that using web services hosted on VLAN20 from VLAN99 through SE has massive delays (developer tools in browser shows constant pending for assets; multiple refreshes finally loads everything---not even sure where to begin there--everything else works fine) so I'll end up going back to the SecureNAT which works just fine in this case (from my 4.x Hyper-V install.)

At least I got it separated from Hyper-V, I'll take the win where I can.

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Wed Jun 04, 2025 4:12 pm
by chrisw
Looks like I solved the delay issue by using a tap_ and br0 -- will continue testing and mucking around with routing.

Re: Debian - SE 4.x/5.x Bridge DHCP Issues - ALMOST THERE

Posted: Wed Jun 04, 2025 7:22 pm
by chrisw
Solved the routing issue as well:

Code: Select all

iptables -t nat -A POSTROUTING -s 10.220.99.0/24 -o tap_soft -j MASQUERADE
iptables -A FORWARD -i enp4s0 -o tap_soft  -j ACCEPT
iptables -A FORWARD -i tap_soft  -o enp4s0 -j ACCEPT
Many thanks to the author of this thread for providing me the clue I needed:

viewtopic.php?f=7&t=69657