FreeBSD setup and operation

Post your questions about SoftEther VPN software here. Please answer questions if you can afford.
Post Reply
tickerguy
Posts: 10
Joined: Mon Oct 17, 2022 9:53 pm

FreeBSD setup and operation

Post by tickerguy » Mon Oct 17, 2022 10:08 pm

I'm attempting to set this up on 12.3, but will soon move the server involved to 13.1.

Right now its a "proof of concept" so I stuck the code (loaded as a package), grabbed the windows configuration GUI problem and ran into a few problems.

First, with a bridge enabled the software continually tries to tamper with the interface MTU (1500) -- raising it. While the adapter can do jumbo frames up to 8k, it wants more -- and as it resets it whacks out the interface with an up/down cycle, and also due to other hosts not liking them on the same switch, it causes general mayhem.

2022-10-17 18:02:37.569 Administration mode [RPC-35]: The Local Bridge connection definition "VPN" --> "igb0" has been added.
2022-10-17 18:02:37.569 [HUB "VPN"] The Local Bridge connection "igb0" has started. The bridge session "SID-LOCALBRIDGE-3" was created.
2022-10-17 18:02:37.852 [HUB "VPN"] Session "SID-LOCALBRIDGE-3": A Local Bridge connection to physical Ethernet interface "igb0" was started.
2022-10-17 18:02:46.570 [HUB "VPN"] Session "SID-LOCALBRIDGE-3": The physical Ethernet interface "igb0" has an MTU value set to 1514. It is necessary to send and receive an Ethernet packet which has 2848 bytes. The MTU is now changed to 2848.
2022-10-17 18:02:59.403 [HUB "VPN"] Session "SID-LOCALBRIDGE-3": The physical Ethernet interface "igb0" has an MTU value set to 2848. It is necessary to send and receive an Ethernet packet which has 2962 bytes. The MTU is now changed to 2962.
2022-10-17 18:03:09.666 [HUB "VPN"] Session "SID-LOCALBRIDGE-3": The physical Ethernet interface "igb0" has an MTU value set to 2962. It is necessary to send and receive an Ethernet packet which has 4088 bytes. The MTU is now changed to 4088.
2022-10-17 18:03:20.007 Administration mode [RPC-35]: The Local Bridge connection definition "VPN" --> "igb0" has been deleted.
2022-10-17 18:03:20.136 [HUB "VPN"] The Local Bridge connection "igb0" has stopped.

This continues until it runs into the jumbo frame limit (8k) and keeps trying to raise it further, which trashes communication as each of those changes down/ups the interface.

I found no way to stop this other than shut down the bridge -- but that may be causing the next problem, as it may have to be there for the rest to work.

I successfully loaded the certificate and CA I need to use, and then attempted to configure a Windows 11 client. After some fumbling (I'll figure out certificates, which I want to use, once I have the basics working) including making sure the CAs are in the right place and such I have gotten to here:

2022-10-17 17:44:50.263 On the TCP Listener (Port 4443), a Client (IP address 172.58.146.152, Host name "172.58.146.152", Port number 19244) has connected.
2022-10-17 17:44:50.263 For the client (IP address: 172.58.146.152, host name: "172.58.146.152", port number: 19244), connection "CID-6" has been created.
2022-10-17 17:44:50.503 SSL communication for connection "CID-6" has been started. The encryption algorithm name is "TLS_AES_256_GCM_SHA384".
2022-10-17 17:44:57.822 SSTP PPP Session [172.58.146.152:19244]: A new PPP session (Upper protocol: SSTP) is started. IP Address of PPP Client: 172.58.146.152 (Hostname: "172.58.146.152"), Port Number of PPP Client: 19244, IP Address of PPP Server: 192.168.10.100, Port Number of PPP Server: 4443, Client Software Name: "Microsoft SSTP VPN Client", IPv4 TCP MSS (Max Segment Size): 0 bytes
2022-10-17 17:44:58.389 On the TCP Listener (Port 0), a Client (IP address 172.58.146.152, Host name "172.58.146.152", Port number 19244) has connected.
2022-10-17 17:44:58.389 For the client (IP address: 172.58.146.152, host name: "172.58.146.152", port number: 19244), connection "CID-7" has been created.
2022-10-17 17:44:58.389 SSL communication for connection "CID-7" has been started. The encryption algorithm name is "(null)".
2022-10-17 17:44:58.389 [HUB "VPN"] The connection "CID-7" (IP address: 172.58.146.152, Host name: 172.58.146.152, Port number: 19244, Client name: "Microsoft SSTP VPN Client", Version: 4.38, Build: 9760) is attempting to connect to the Virtual Hub. The auth type provided is "External server authentication" and the user name is "karl".
2022-10-17 17:44:58.389 [HUB "VPN"] Connection "CID-7": Successfully authenticated as user "karl".
2022-10-17 17:44:58.389 [HUB "VPN"] Connection "CID-7": The new session "SID-KARL-[SSTP]-2" has been created. (IP address: 172.58.146.152, Port number: 19244, Physical underlying protocol: "Legacy VPN - SSTP")
2022-10-17 17:44:58.389 [HUB "VPN"] Session "SID-KARL-[SSTP]-2": 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.
2022-10-17 17:44:58.389 [HUB "VPN"] Session "SID-KARL-[SSTP]-2": VPN Client details: (Client product name: "Microsoft SSTP VPN Client", Client version: 438, Client build number: 9760, Server product name: "SoftEther VPN Server (64 bit) (Open Source)", Server version: 438, Server build number: 9760, Client OS name: "Microsoft SSTP VPN Client", Client OS version: "-", Client product ID: "-", Client host name: "172.58.146.152", Client IP address: "172.58.146.152", Client port number: 19244, Server host name: "192.168.10.100", Server IP address: "192.168.10.100", Server port number: 4443, Proxy host name: "", Proxy IP address: "0.0.0.0", Proxy port number: 0, Virtual Hub name: "VPN", Client unique ID: "474A5C384098E408C77393EC362CE77C")
2022-10-17 17:44:58.670 SSTP PPP Session [172.58.146.152:19244]: Trying to request an IP address from the DHCP server.
2022-10-17 17:45:03.677 SSTP PPP Session [172.58.146.152:19244]: Acquiring an IP address from the DHCP server failed. To accept a PPP session, you need to have a DHCP server. Make sure that a DHCP server is working normally in the Ethernet segment which the Virtual Hub belongs to. If you do not have a DHCP server, you can use the Virtual DHCP function of the SecureNAT on the Virtual Hub instead.
2022-10-17 17:45:11.777 SSTP PPP Session [172.58.146.152:19244]: The VPN Client sent a packet though an IP address of the VPN Client hasn't been determined.
2022-10-17 17:45:11.777 SSTP PPP Session [172.58.146.152:19244]: A PPP protocol error occurred, or the PPP session has been disconnected.
2022-10-17 17:45:11.809 Connection "CID-6" terminated by the cause "Connection has been disconnected." (code 3).
2022-10-17 17:45:11.809 Connection "CID-6" has been terminated.
2022-10-17 17:45:11.809 The connection with the client (IP address 172.58.146.152, Port number 19244) has been disconnected.

There IS a DHCP server on the base network but I see nowhere I can specify its address (it is not on the same host where the connection is coming into.) If the problem is that the bridge has been shut down and its needed to get the packets on the wire then fixing the "I wanna crank up the MTU" problem is the gating factor, and I can't find a place to shut that off, if it can be shut off.

Any suggestions?

tickerguy
Posts: 10
Joined: Mon Oct 17, 2022 9:53 pm

Re: FreeBSD setup and operation

Post by tickerguy » Tue Oct 18, 2022 2:47 pm

Further possible hint: I reset the MTU on the igb0 interface manually (back to 1500); the system logged this once:

2022-10-18 10:44:16.723 [HUB "VPN"] Session "SID-LOCALBRIDGE-4": The physical Ethernet interface "igb0" has an MTU value set to 8814. It is necessary to send and receive an Ethernet packet which has 14654 bytes. However, changing the MTU to 14654 failed. This physical Ethernet interface or device driver might be unable to process an Ethernet packet which has more 1,514 bytes (payload size: 1,500 bytes). In such case, the larger tagged-VLAN packets than 1,514 bytes cannot be transmitted. You should replace the current physical Ethernet adapter to another which supports Jumbo Frames. You can also try to update the device driver. Another possible method is to enable Jumbo Frames on the operating system or device driver settings.

I don't need tagged-VLAN at all for this installation. The network itself does have tagged-VLAN on it, but its of no relevance for this particular use as the tagged vlan traffic is segregated off and will not be relevant to this install. However, I don't see a way to shut that off that's obvious.

tickerguy
Posts: 10
Joined: Mon Oct 17, 2022 9:53 pm

Re: FreeBSD setup and operation

Post by tickerguy » Tue Oct 18, 2022 4:53 pm

Update: Perusing through the code it appears that the offending function gates off EthIsChangeMtuSupported(interface), which in turn checks first to see if its on a Unix box, and then if it is looks for either Tap mode (which is Linux-only) or if IsRawIpMode is set; in either case it returns false and the code would not play with the interface MTU.

The only place I see the latter set is in OpenEthLinuxIpRaw(), which in turn is enabled only on Linux. I'm on FreeBSD, ergo it looks like there is no configuration option that will stop the code from attempting to run "jumbo" packets all the way up to whatever it tries to send at once and any attempt to send a packet larger than the MTU results in it trying to set the MTU higher. My Intel interfaces can run ~8k jumbo frames but the code tries to incrementally go larger even when it reaches that point and every time it tries to play with the MTU the interface is set down and then up in order to do so, which is wildly disruptive to everything that has network connections open.

Unless I'm missing something in the config that would prevent the code from doing this that's seriously wrong and may make it unusable on an other-than-Linux environment. Since its claimed to run on other Unix variants that would imply I am missing something somewhere....

tickerguy
Posts: 10
Joined: Mon Oct 17, 2022 9:53 pm

Re: FreeBSD setup and operation

Post by tickerguy » Tue Oct 18, 2022 6:08 pm

I got the bridge problem sorted.

I will file a bug report with FreeBSD's "ports" system as well, and/or here if there's a method to do so (or someone here in the project may wish to do so if there is no base "pull" request setup; I do see a .github directory but its not clear there's a formal submission procedure. in any event this is the fix for FreeBSD operable against (at least) 12.x and 13.1.

In Cedar/BridgeUnix.c

Code: Select all

// Is changing MTU supported?
bool EthIsChangeMtuSupported(ETH *e)
{
#if     defined(UNIX_LINUX) || defined(UNIX_BSD) || defined(UNIX_SOLARIS)
        // Validate arguments
        if (e == NULL || e->Tap != NULL)
        {
                return false;
        }

        if (e->IsRawIpMode)
        {
                return false;
        }
#ifndef __FreeBSD__
        return true;
#else
        return false;
#endif
#else   // defined(UNIX_LINUX) || defined(UNIX_BSD) || defined(UNIX_SOLARIS)
        return false;
#endif  // defined(UNIX_LINUX) || defined(UNIX_BSD) || defined(UNIX_SOLARIS)
}
This blocks the MTU changes on FreeBSD and the code runs without incident; I am able to connect from a client and access things on the "inside", other than below.

My remaining issue is that while I get the DHCP assignment as its on a different host I cannot see the server host itself or any of the things operating on it. I recall something in the documentation about this, and it will be a problem as where I want this server on a permanent basis is on the same host where the DHCP server resides -- and is also where the default gateway is for the network is as well.

Is the "correct" way to do this to define a separate pool under the SecureNAT tab, do not select the virtual NAT function (since I don't need it; that machine already does NAT on outbound for me) and use only the separate DHCP server functionality and define a separate subnet that is active only for these clients?

Thanks in advance.

solo
Posts: 1228
Joined: Sun Feb 14, 2021 10:31 am

Re: FreeBSD setup and operation

Post by solo » Tue Oct 18, 2022 9:09 pm

Re: source code patch, submit it here https://github.com/SoftEtherVPN/SoftEtherVPN/issues

Re: the server host access:
The cause of this restriction lies with OS's internal kernel codes rather than with the SoftEther VPN. When wishing to communicate in any form with a UNIX computer used for local bridging from the VPN side (Virtual Hub side), (for instance, when running both the VPN Server / VPN Bridge service & the HTTP Server service and wishing to grant access to the server service from the VPN side as well), prepare and connect a local bridge network adapter and physically connect both it and the existing network adapter to the same segment
https://www.softether.org/4-docs/1-manu ... r_Mac_OS_X

tickerguy
Posts: 10
Joined: Mon Oct 17, 2022 9:53 pm

Re: FreeBSD setup and operation

Post by tickerguy » Tue Oct 18, 2022 9:39 pm

Yep, I figured that one out -- stuck another (USB) adapter on there, set that one as the bridge, all works as expected.

Reported w/patch on Github.

-- Thanks!

tickerguy
Posts: 10
Joined: Mon Oct 17, 2022 9:53 pm

Re: FreeBSD setup and operation

Post by tickerguy » Wed Oct 19, 2022 12:52 pm

This may be a Windows limitation in their SSTP client; not certain....

The environment is the server as-above and the client is a Windows 11 machine using the internal Microsoft VPN software for SSTP.

SSTP authentication with a username and password works as expected. However, attempting to set connection authentication to "Certificate" on the client and "Signed Certificate Authentication" on the server, with the correct CAs set on both ends the connection is immediately dumped by the server with the following:

2022-10-18 23:01:23.335 On the TCP Listener (Port 443), a Client (IP address 192.168.10.14, Host name "D4.Denninger.Net", Port number 55070) has connected.^M
2022-10-18 23:01:23.335 For the client (IP address: 192.168.10.14, host name: "D4.Denninger.Net", port number: 55070), connection "CID-8" has been created.^M
2022-10-18 23:01:23.453 SSL communication for connection "CID-8" has been started. The encryption algorithm name is "TLS_AES_256_GCM_SHA384".^M
2022-10-18 23:01:23.590 SSTP PPP Session [192.168.10.14:55070]: A new PPP session (Upper protocol: SSTP) is started. IP Address of PPP Client: 192.168.10.14 (Hostname: "D4.Denninger.Net"), Port Number of PPP Client: 55070, IP Address of PPP Server: 97.81.26.48, Port Number of PPP Server: 443, Client Software Name: "Microsoft SSTP VPN Client", IPv4 TCP MSS (Max Segment Size): 0 bytes^M
2022-10-18 23:01:23.590 SSTP PPP Session [192.168.10.14:55070]: The client denied to accept both the "PAP" (Password Authentication Protocol, a clear-text password authentication protocol) and MS-CHAP v2 Protocol. Enable either PAP or MS-CHAP v2 on the client-side and retry.^M
2022-10-18 23:01:23.590 SSTP PPP Session [192.168.10.14:55070]: A PPP protocol error occurred, or the PPP session has been disconnected.^M
2022-10-18 23:01:23.621 Connection "CID-8" terminated by the cause "Connection has been disconnected." (code 3).^M
2022-10-18 23:01:23.621 Connection "CID-8" has been terminated.^M
2022-10-18 23:01:23.621 The connection with the client (IP address 192.168.10.14, Port number 55070) has been disconnected.^M

Why would the server want a password when its been told to expect a certificate? Is the issue that the server has no idea who the client is (that is, there is nothing to compare the "user" field to) and, if so, I see nothing in the exchange here that I can reasonably use as a match in the "user" field. The screen says to use "*" for RADIUS and similar, but I'm not using Radius and it will not allow me to save a wildcard username without external authentication.

I found this in the security log:
2022-10-18 22:50:06.583 The connection "CID-3" (IP address: 192.168.10.14, Hostname: D4.Denninger.Net, Port number: 54663, Client name: "Microsoft SSTP VPN Client", Version: 4.38, Build: 9760) is attempting to connect to the Virtual Hub. The auth type provided is "External server authentication" and the user name is ".\Karl".^M
2022-10-18 22:50:06.583 Connection "CID-3": User authentication failed. The user name that has been provided was ".\Karl".^M

But... I can't set the username to that string; the "ok" grays out when I key the backslash. (I presume the "." is due to not being on a domain controller.)
Last edited by tickerguy on Wed Oct 19, 2022 2:06 pm, edited 1 time in total.

solo
Posts: 1228
Joined: Sun Feb 14, 2021 10:31 am

Re: FreeBSD setup and operation

Post by solo » Wed Oct 19, 2022 2:01 pm

SoftEther VPN doesn't support certificate authentication on SSTP protocol.
https://www.vpnusers.com/viewtopic.php? ... 797#p10797

tickerguy
Posts: 10
Joined: Mon Oct 17, 2022 9:53 pm

Re: FreeBSD setup and operation

Post by tickerguy » Wed Oct 19, 2022 2:07 pm

Ah.... got it.

Incidentally the entire point of this is exercise for me is that it appears T-Mobile in the US has started blocking port 4500 UDP upbound from tethered (and only tethered) devices. It connects, the connected client gets traffic intended for it but nothing comes back to the server at all except the keep-alive maintenance packets on port 500. This is a relatively new thing; it was working a month or so back and has been working perfectly well for many years (since Microsoft fixed the IKE fragmentation bogon anyway.)

This of course blows up IKEv2 connections but only from tethered devices -- the Android StrongSwan client works perfectly well and thus I have to assume its intentional on their part.

eddiewu
Posts: 286
Joined: Wed Nov 25, 2020 9:10 am

Re: FreeBSD setup and operation

Post by eddiewu » Thu Oct 20, 2022 2:28 am

SSTP with certificate authentication is supported in the developer edition.

https://github.com/SoftEtherVPN/SoftEth ... le-edition

tickerguy
Posts: 10
Joined: Mon Oct 17, 2022 9:53 pm

Re: FreeBSD setup and operation

Post by tickerguy » Thu Oct 20, 2022 2:31 am

I will grab that and play with it.... thanks, I had missed that comparison chart.

tickerguy
Posts: 10
Joined: Mon Oct 17, 2022 9:53 pm

Re: FreeBSD setup and operation

Post by tickerguy » Thu Dec 08, 2022 6:54 pm

Quick question I can't find with a relatively rapid search in the manual:

Is there a way to specify that you want softether_server to listen only on a given interface (or address, which would imply the same thing)?

The declare ListenerList{} stanza only enables a port, which then binds to address "*" (everything), and shows up commensurately in netstat.

The reason I ask if I can restrict this is that I am running into an interface flapping problem and it appears that the VPN Server is the cause. I'm running softether5 (the "alpha/beta" code) and do have the MTU fix enabled that I put up as a pull request and was, with another addition from someone else, accepted.

The flap is happening on the ue interface that I must have connected for the bridge, but some of the time when it occurs it is causing a connectivity loss on the main external interface, which then forces a resync (and re-dhcp pull) from the upstream provider, with fairly disruptive impact on connectivity. If I shut down softether it doesn't happen. I've not been able to isolate it successfully to the specific section of code involved thus far, but suspect it may be related to the ue flaps (which happen even if softether is not running at all or even if the cable is not connected to the USB dongle so the code isn't the cause -- but might trigger bad behavior when it occurs.) The reason I suspect this is related is that the wildcard binding means that interface, when it flaps, both loses and then re-allocates the IP address that's on it which is necessary for the bridge to work and permit access to local resources on that box (including the DNS resolver and DHCP server, both of which you have to have for a VPN connection to be functional.)

If I can bind ONLY to the external interface then that shouldn't be a factor and I can either eliminate or mitigate the problem being related to the softether5 code, but I see nothing in the config file or GUI that permits this.

Can it be done?

solo
Posts: 1228
Joined: Sun Feb 14, 2021 10:31 am

Re: FreeBSD setup and operation

Post by solo » Fri Dec 09, 2022 11:12 am

tickerguy wrote:
Thu Dec 08, 2022 6:54 pm
Can it be done?
Yes, "ListenIP" https://github.com/SoftEtherVPN/SoftEtherVPN/pull/202

tickerguy
Posts: 10
Joined: Mon Oct 17, 2022 9:53 pm

Re: FreeBSD setup and operation

Post by tickerguy » Fri Dec 09, 2022 2:19 pm

That's only a partial solution (and one that can result in no-service) which I why I asked if you could either include or exclude interfaces.

Consider the case where the VPN server is on the Internet Gateway which gets a dynamic address. Since you don't have a fixed address if you stick an actual address to bind to in the config and it moves out from under you (and it might) you now have nothing. You can handle the DNS side of it with dynamic zone updates run out of the DHCP client which is pretty easy to set up but there is no reasonable way for softether to "follow" that, unless you wrote something to hook that dynamic update, edit the config file and force a reload.

Further in cases where the gateway is multi-homed being able to exclude or include interfaces rather than a specific listening IP is required otherwise you will listen only one of the IP addresses that the outside party might connect to rather than all of them.

Post Reply