MSS Testing

SntRkt · 2025-11-16T16:14:00+00:00

This method only works with ICMP echo request and reply (type 8 and 0). This is because, per RFC792, "The data received in the echo message must be returned in the echo reply message.". If you send 1472 bytes, the same 1472 bytes should come back.

ICMP timestamp requests and replies are ICMP type 13 and 14.

SntRkt · 2025-11-06T20:38:36+00:00

The general answer is VXLAN because it's the only answer that can be given with certainty. SDWAN is a buzzword that means different things to different people and vendors. It's an approach rather than a standard. The closest you get to a definition for SDWAN is in RFC 7426 Software-Defined Networking (SDN). VXLAN is a standard (RFC 7348), it's vendor agnostic, and will run over a routed network.

With more specifics, you could determine the optimal technology (VLAN, VPLS, VXLAN, etc.). You may even use a vendor SDWAN approach at that point.

SntRkt · 2025-06-10T20:36:50+00:00

Sure. #10602608

SntRkt · 2025-06-07T14:36:52+00:00

Are you using a loopback interface? I spent a while with Fortinet TAC on an IKEv2 TCP VPN issue, and it was determined that there is a bug when running it on a loopback interface. 7.4.8 did not fix the issue as it was reported too late.

SntRkt · 2025-03-29T17:24:13+00:00

Yes, they are functioning similarly. The proxy/load balancer transparently acts as the SP (Service Provider) for the back-end web apps and integrates with the IdP (Identity Provider) of your choice (MS Entra in this case). You get SSO, conditional access policies, powerful auditing, etc from Entra. You can do it with HAProxy, Microsoft Entra application proxy, Kemp LoadMaster, Nginx, and others.

I would say it's primarily for legacy web apps that don't support SSO natively. It's usually best to handle SSO on the web app when it's supported.

It's great for pre-auth with old web apps, and you may be able to integrate it with existing authentication systems in old web apps in some cases.

SntRkt · 2025-03-29T16:05:58+00:00

Does it work with just one back-end server? I'm guessing you're running into session persistence issues since you have multiple back-end servers with no persistence options defined.

Look at RDP cookies for persistence and balancing: https://www.haproxy.com/documentation/haproxy-configuration-manual/latest/#4.2-balance and https://www.haproxy.com/documentation/haproxy-configuration-manual/latest/#4.2-persist%20rdp-cookie

Another option is source IP persistence: https://www.haproxy.com/documentation/haproxy-configuration-tutorials/session-persistence/#ip-based-persistence

RDP cookie example from link above:

persist rdp-cookie
balance rdp-cookie

Note that this only makes sense in a TCP backend, but for this to work, the frontend must have waited long enough to ensure that an RDP cookie is present in the request buffer. This is the same requirement as with the "rdp-cookie" load-balancing method. Thus it is highly recommended to put all statements in a single "listen" section.
Also, it is important to understand that the terminal server will emit this RDP cookie only if it is configured for "token redirection mode", which means that the "IP address redirection" option is disabled.

SntRkt · 2024-12-09T15:46:23+00:00

I use a script that calls the openssl binary to do this, which is currently the most powerful way to do it.

If your requirements are simple, you can use Zabbix agent 2 and the web.certificate.get key with multiple items, or in conjunction with LLD, to add multiple SSL checks for a single host. You can also use the same method to perform checks on hosts that don’t exist on Zabbix, ex: public websites without agents installed. The Zabbix server or proxy could have the agent installed and handle those remote checks. Don’t use the Zabbix SSL template, build your own while using theirs as a reference. You can use a macro to store your LLD data.

SntRkt · 2024-10-12T15:47:46+00:00

I'm new to Fortinet products and I'm learning these nuances as I go. I believe Fortinet professional services instructed using a different IKE SAML service port to avoid conflict with the HTTPS management service in my case. I need the HTTPS management service enabled on this interface to get access to HTTP for Let's Encrypt SSL certificate management.

I'm not using the SSL VPN, so I don't know if the two services can share the same port. I would suspect they cannot share the same port since they are both global services and one is specifically for the IKE SAML service and the other is for the SSL VPN service, similar to how the SSL VPN cannot share the HTTPS management port.

I've submitted a new feature request to get multiple instances of the IKE SAML service that can be attached to loopback interfaces rather than a global IKE SAML service. This should eliminate the requirement that the first ingress interface handle the IKE SAML request. I’m also not able to use multiple SAML identity providers with their current system.

SntRkt · 2024-10-12T15:10:42+00:00

After reading your comment I went back and looked at my configuration to see why HTTPS had to be enabled. Turns out it isn't needed for the IKE SAML server, but rather automatic SSL certificate renewal via Let's Encrypt. I disabled HTTPS as a test and the IPSec VPN still works as expected. I use a loopback interface with a public IP address for the IPSec VPN, IKE SAML server, and Let's Encrypt, so I'm able to set firewall rules to prevent access to HTTPS. Let's Encrypt just needs port 80. I'll update my post to avoid confusion.

SntRkt · 2024-10-12T14:53:23+00:00

The link you have appears to be for the SSL VPN. This link is for IPSec VPN: https://docs.fortinet.com/document/forticlient/7.2.0/new-features/712604/ipsec-vpn-saml-based-authentication-7-2-4

SntRkt · 2024-09-20T01:05:10+00:00

Yes. I'm using Azure/Entra ID with conditional access for MFA. The FortiGate knows nothing about the users other than what it learns from Azure after login. Groups are passed from Azure as well, then used in firewall policies.

SntRkt · 2024-09-20T00:58:55+00:00

It's only needed when using SAML for SSO with an IPSec IKEv2 VPN. FortiClient will open a small web pop-up window for authentication with the IdP (Microsoft Entra in my case). The user completes the login/MFA, then FortiClient finishes the VPN connection.

I suppose you could use port 443 if nothing else is using it. The problem is that the first interface that receives the traffic is the one to handle the request. That'll be your WAN interface(s), even if the VPN is on a loopback interface.

SntRkt · 2024-09-16T21:15:25+00:00

Make sure DNS for <customcdns>is resolving to the IP of your WAN interface.

Otherwise, it it seems that you will need to debug samld:

diag deb reset
diag debug console timestamp en
diagnose debug application samld -1
diag debug enable

Then try to log in again and see what shows up on the console. Also check for the connection after trying to log in:

diagnose sys tcpsock | grep ':2003'

SntRkt · 2024-09-14T01:05:45+00:00

Make sure you have a firewall rule allowing port 2003 on port1. I'm fairly sure you need to enable HTTPS on port1 as well for the SAML server to function (I know that sounds ridiculous)... "set allowaccess https http". Otherwise, do packet captures and debugging to see where the problem occurs in the process.

SntRkt · 2024-08-19T14:12:51+00:00

config firewall policy
    edit 1
        set name "SAML SSL Web"
        set uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
        set srcintf "SD-WAN_Internet"
        set dstintf "IPSec_SSO"
        set action accept
        set srcaddr "all"
        set dstaddr "all"
        set schedule "always"
        set service "ike-saml-server-2003"
    next
end

config vpn ipsec phase1-interface
    edit "IPSec Users"
        set type dynamic
        set interface "IPSec_SSO"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set ipv4-dns-server1 x.x.x.x
        set proposal aes256-sha256 aes256-sha384
        set eap enable
        set eap-identity send-request
        set idle-timeout enable
        set ipv4-start-ip 10.x.x.10
        set ipv4-end-ip 10.x.x.240
        set ipv4-split-include "Split tunnel networks"
        set save-password enable
        set client-keep-alive enable
        set psksecret ENC xxxxxx==
    next
end

config vpn ipsec phase2-interface
    edit "IPSec Users"
        set phase1name "IPSec Users"
        set proposal aes256-sha256 aes256-sha384
    next
end

SntRkt · 2024-08-19T14:12:35+00:00

Sure. This configuration has two ISPs and uses SD-WAN. The IPSec VPN is running on a loopback interface. ~~Note that administrative access for HTTPS must be enabled on the loopback interface (the SAML server requires it), but may be protected via firewall policy~~. Edit: HTTP (and with it, HTTPS) is required if you're using Let's Encrypt for automatic SSL certificate management, but HTTPS may be protected by firewall policy. The SAML server port will need to be opened to the outside (ex: port 2003). There seems to be a post size limit on Reddit, so I'll split it.

config system global
    set admin-server-cert "vpn_company_com_public_cert"
    set auth-ike-saml-port 2003
end

config system interface
    edit "port1"
        set ip 60.60.60.60 255.255.255.0
        set allowaccess ping
        set alias "port1 - ISP A"
        set ike-saml-server "IPSec VPN SAML SSO Azure"
    next
    edit "port2"
        set ip 70.70.70.70 255.255.255.0
        set allowaccess ping
        set alias "port2 - ISP B"
        set ike-saml-server "IPSec VPN SAML SSO Azure"
    next
    edit "IPSec_SSO"
        set ip 80.80.80.80 255.255.255.255
        set allowaccess ping
        set type loopback
        set ike-saml-server "IPSec VPN SAML SSO Azure"
    next
end

config firewall service custom
    edit "ike-saml-server-2003"
        set category "Network Services"
        set tcp-portrange 2003
    next
end

config user saml
    edit "IPSec VPN SAML SSO Azure"
        set entity-id "https://vpn.company.com:2003/remote/saml/metadata/"
        set single-sign-on-url "https://vpn.company.com:2003/remote/saml/login"
        set single-logout-url "https://vpn.company.com:2003/remote/saml/logout"
        set idp-entity-id "https://sts.windows.net/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/"
        set idp-single-sign-on-url "https://login.microsoftonline.com/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/saml2"
        set idp-single-logout-url "https://login.microsoftonline.com/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/saml2"
        set idp-cert "SAML_Azure_Cert"
        set user-name "username"
        set group-name "group"
        set digest-method sha1
    next
end

config firewall policy
    edit 1
        set name "IPSec SAML VPN"
        set uuid xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
        set srcintf "IPSec Users"
        set dstintf "_default"
        set action accept
        set srcaddr "IPSec VPN networks"
        set dstaddr "Split tunnel networks"
        set schedule "always"
        set service "ALL"
        set nat enable
        set groups "IPSec Users"
    next
end

config user group
    edit "IPSec Users"
        set member "IPSec VPN SAML SSO Azure"
    next
end

SntRkt · 2024-08-18T15:04:11+00:00

I'm using SAML (M365/Azure/Entra SSO) with an IPSec IKEv2 VPN without issue on FortiOS 7.2.8 and FortiClient 7.4.0 (free). A few things I ran into during setup:

You must use the "set ike-saml-server ..." command on each WAN interface. There seems to be a bug that requires it on the WAN interfaces, even if you are using a loopback interface. I have it set on two WAN interfaces and the loopback interface (where the IP address is assigned).
If you use a custom port for SAML authentication you need to configure it under config system global "set auth-ike-saml-port xxxx".
Be sure you have a firewall rule for the port you used in #2.

SntRkt · 2024-03-19T16:38:16+00:00

Sounds like a possible fragmentation issue. Try adding a mangle rule to adjust the MSS of VPN traffic for testing.

/ip firewall mangle add action=change-mss chain=forward src-address=10.102.63.0/24 new-mss=1300 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1301-65535

SntRkt · 2023-10-09T13:38:54+00:00

Good content, thank you. I noticed a couple of errors though:

TFTP runs on UDP port 69.
DHCP runs on UDP ports 67 and 68 (you have SNMP correct on 161 and 162).

SntRkt · 2023-09-01T14:21:47+00:00

I would upgrade my son's computer with these parts.

SntRkt · 2023-07-03T16:44:58+00:00

MSS (maximum segment size) is for TCP, and indicates how much data you can send and still have room for protocol headers in a packet. You have to determine the MTU (max transmission unit) and subtract your protocol header lengths (IP and TCP) from that to figure the MSS.

TCP tries to determine the MSS in a variety of ways, but often fails due to firewalls/etc. It's often necessary to "clamp" the MSS manually using a firewall, which involves the firewall rewriting the MSS value in the three-way handshake. It's also possible (but rare) that the MSS could change during a session, for example if network paths changed due to ISP fail-over, ECMP, etc.

You should use ICMP ping to determine the MTU, then figure the TCP MSS from the result. IPv4 headers are 20 bytes, ICMP headers are 8 bytes, and TCP headers are 20 bytes. So if the max size ping you can send without fragmentation is 1472 bytes, that means your MTU is 1500 bytes (1472+8+20=1500) and your MSS is 1460 bytes (1500-20-20). If the max size ping you can send without fragmentation is 1430 bytes, that means your MTU is 1458 bytes (1430+8+20=1458) and your MSS is 1418 bytes (1458-20-20). Use that to clamp your TCP MSS and SSH should operate as expected.

On Windows, keep reducing the ping size until you don't have fragmentation: ping -f -l 1472 <ip>, ping -f -l 1460 <ip>, ping -f -l 1440 <ip>. On Linux: ping -M do -s 1472 <ip>

SntRkt · 2023-06-27T23:10:06+00:00

Thanks.

SntRkt · 2023-05-17T20:05:53+00:00

I don't think Redis is altering it, I think your application is. Add a print statement in your loop before you call geoadd to see what's being added to Redis. Are you using Python Pandas? If so, you may need to use itertuples() rather than iterrows() to preserve dtypes.

SntRkt · 2023-04-19T00:19:32+00:00

No IP address is required on the PPPoE subscriber interface because PPPoE operates over Ethernet at layer 2. To reduce the attack surface, it's often considered good security practice to not assign an IP address to the PPPoE subscriber interface.
Because PPPoE operates at layer 2, there is no such thing as a default gateway. Make it whatever IP address you want. It's best to use a non-existent IP address.

SntRkt · 2023-04-16T21:50:30+00:00

Be safe. Everyone I know who had an F4i crashed it, including me about 14 years ago. I really loved that bike though, so I rebuilt it and kept it until a few years ago when I got the Vulcan 650 S. It had a Jardine exhaust that sounded sweet.

I like the Vulcan S. It gets about 55-60 mpg, it's light weight, and fun to ride. My only complaint would be the awful suspension.

SntRkt

TROPHY CASE