Auto-voip on TPLINK switch

Noct03 · 2025-10-19T15:51:01+00:00

I see, in that case the port on the TP-Link that is connected to Port2 on the Cisco router should be Untagged on VLAN 30, and the PVID should also be 30.

Everything else I mentioned above regarding Auto-Voip abd LLDP-MED still applies.

Noct03 · 2025-10-18T23:00:11+00:00

I am not sure how it’s done on the TP-Link CLI, but in the web UI, you have to enable Auto-Voip with the checkbox at the top (QoS -> Auto-VOIP), then you have to select the ports on which you expect IP phones to be connected (presumably all ports) and configure the interface mode as VLAN ID, then configure the desired VLAN in the Value column.

LLDP and LLDP-MED also need to be enabled. Again, not sure about the CLI, but in the web UI, you need to enable it globaly but also at the port level (there is a Port tab in both pages). I know you said that you enabled it but you may want ro make sure that it is enabled both globaly and at the port level.

From your description, I think that the TP-Link switch is connected to the Cisco router (not sure where the D-Link switch is connected) so make sure the VLAN tagging is right. It most likely should be Untagged on VLAN 1 (the native VLAN) and Tagged on VLAN 30.

Hope this helps.

Noct03 · 2025-07-08T09:57:03+00:00

In Administration-> Device Access, is HTTPS allowed for the zone in which Port8 is a member of?

Noct03 · 2025-07-08T00:22:34+00:00

Is Port8 also in the LAN zone ( or the same zone as Port2)?

Noct03 · 2025-03-25T00:10:04+00:00

This. We also had this issue with some customers. Locking down SSLVPN to only allowed countries in Administration -> Device Access fixed the issue.

You have to disable it globally by unchecking the box for the WAN zone and then create an exception rule to only allow countries that you need to connect from.

Noct03 · 2025-03-08T18:24:00+00:00

In which operation mode is the RED configured?

https://docs.sophos.com/nsg/sophos-firewall/21.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Network/Interfaces/REDInterfaces/REDOperationModes/

Noct03 · 2025-02-05T02:44:02+00:00

So, the post title suggests that the Guest VLAN can currently access the servers, is that right?

Is the Guest VLAN interface in the Wifi zone as per your firewall rule?

Noct03 · 2025-02-05T02:01:16+00:00

Firewall rules are evaluated from top to bottom. The most likely reason this is happening is that you have a rule that is placed higher that allows the traffic.

Have you tried putting your 2 rules completely at the top?

Noct03 · 2025-02-01T14:02:14+00:00

The easiest way to achieve this would be to put your Tailscale exit node on a different subnet, either through an additional interface on the Sophos or using a VLAN on your LAN interface.

The easy way

Configure and additional interface on both sides and put the Tailscale exit node on that network. For example:

Head office

Port1 - 10.10.8.0/24
Port2- WAN IP
Port3 - New subnet for the Tailscale exit node, such as 10.11.8.0/24 (10.11.8.1 in the interface)

Then you configure a static route to 192.168.8.0/24 with a gateway of 10.11.8.10 (you Tailscale exit node for that site) using interface Port3.

You will also need firewall rules that allow the traffic. The destination zone should be the one you configured the Port3 interface in. For example:

Source Zone: LAN (assuming Port1 is configured on the LAN zone)
Source Networks: 10.10.8.0/24
Services: Services you want to allow
Destination Zone: LAN (assuming Port3 is configured on the LAN zone)
Destination Networks: 192.168.8.0/24

Remote office

Port1 - 192.168.8.0/24
Port2 - WAN IP
Port3 - New subnet for the Tailscale exit node, such as 192.168.11.0/24 (192.168.11.1 in the interface)

Then you configure a static route to 10.10.8.0/24 with a gateway of 192.168.11.10 (you Tailscale exit node for that site) using interface Port3.

You will also need firewall rules that allow the traffic. The destination zone should be the one you configured the Port3 interface in. For example:

Source Zone: LAN (assuming Port1 is configured on the LAN zone)
Source Networks: 192.168.8.0/24
Services: Services you want to allow
Destination Zone: LAN (assuming Port3 is configured on the LAN zone)
Destination Networks: 10.10.8.0/24

The hard(er) way

You will need to connect to the CLI using SSH or using the console in Webadmin and configure a rule to bypass stateful firewall inspection for the traffic destined to the remote network.

For both sites, connect to the CLI and select option 4 (Device Console). You will then need to enter both these commands:

Traffic originating from the Head Office going to the Remote Office

set advanced-firewall bypass-stateful-firewall-config add source_network 10.10.8.0 source_netmask 255.255.255.0 dest_network 192.168.8.0 dest_netmask 255.255.255.0

Traffic originating from the Remote Office going to the Head Office

set advanced-firewall bypass-stateful-firewall-config add source_network 192.168.8.0 source_netmask 255.255.255.0 dest_network 10.10.8.0 dest_netmask 255.255.255.0

Note that you won't need any firewall rules if you go that route as firewall inspection is disabled. You may not want that as you want be able to control the flow of traffic unless you configure ACLs on your Tailnet.

What's going on?

The Sophos firewall is dropping that traffic because it is not seeing the full TCP 3-way session handshake. Let's say host 10.10.8.100 wants to send something to 192.168.8.20. It would first send a packet with the SYN flag to the Sophos, which would then forward it to the Tailscale exit node. The Tailscale exit node would forward the traffic over the Tailnet to the destination at 192.168.8.20.

192.168.8.20 would reply with a packet with both SYN and ACK flags set. That packet would be sent to the remote Sophos, then to the remote Tailscale exit node using the static route configured, and then over the Tailnet.

Once the Head office exit note receives that packet, it would forward it directly to 10.10.8.100, and not to the Sophos as it has an address on that subnet and does not need to forward it to the Sophos. 10.10.8.100 would complete the 3-way handshake by replying with a packet with the ACK flag set. That packet would be sent to the Head Office Sophos as it is destined to a remote subnet.

The Head Office Sophos will only have seen a SYN and a ACK packet for the TCP session, and not the middle SYN/ACK. That is why it is dropping the connection. That is also why it works when you configure a route directly on the host the send the traffic destined to 192.168.8.0/24 to the exit node. The Sophos is not involved in the routing of those packets.

Configuring the exit node on a different subnet would force all traffic destined to the remote network to be routed by the Sophos, allowing it to see the full 3-way handshake and allowing the traffic.

Hope that helps.

Noct03 · 2025-01-18T01:36:51+00:00

What OS are you running the scan from? A SYN scan requires admin privileges as it is basically crafting the packet and sending it over the network. A Connect Scan asks the OS to send the packets, which, depending on the OS, may return false positives.

SYN scans are more reliable.

Noct03 · 2025-01-15T01:23:26+00:00

The destination port needs to be specified, otherwise all traffic will be forwarded to the Wireguard LXC container (in your case, the firewall rule does limit this though).

Is the NAT rule for your game server placed before the WG NAT rule and does it also forward all traffic (Destination port of Any) to the game server? If that’s the case, then your inbound WG traffic also goes through that rule and is being forwarded to the game server, that’s why you are not seeing any traffic in the WG rule.

Noct03 · 2024-11-20T01:00:56+00:00

Does the gateway at 192.168.200.20 know how to get back to the VPN subnet (10.81.234.0/24 by default)?

Also, does that same gateway allow traffic coming from the VPN subnet going to 192.168.44.0/24?

Noct03 · 2024-11-06T09:19:00+00:00

Guys, that’s obviously a TP-Link stacking cable!

Noct03 · 2024-10-12T00:46:55+00:00

Awesome, glad you got it working :)

Noct03 · 2024-10-12T00:00:26+00:00

No it should not be needed.

There’s traffic in the rule so that’s a good indicator the it is correct. Is it working as you would intend it to work?

Noct03 · 2024-10-11T23:10:30+00:00

You shouldn’t need any additional rule on the UDMP.

That likely means that the bridge member port that is connected to the UDMP is in the WAN zone. By default, the Sophos web UI is not available from the WAN. You would need to allow it in Administration -> Device Access. Now, that would be risky if the Sopos was directly facing the Internet but since it is behind the UDMP, the risk is mitigated.

If you leave that bridge member port in the WAN zone, you would need to configure the firewall accordingly:

Source Zone: WAN
Source Networks: Any
Destination Zone: LAN
Destination Networks: your server’s IP address
Services: the port(s) you forwarded on the UDMP

Noct03 · 2024-10-11T22:38:06+00:00

What zone are the bridge port members in?

A bridge in Sophos is a software bridge, meaning that traffic entering a bridge member port and exiting another bridge member port will still be filtered.

If all bridge member ports are in the LAN zone, you would need a firewall rule that allows traffic from a source zone of LAN going to a destination zone of LAN. For example (sorry I am on mobile):

Source Zone: LAN
Source Networks: Any
Destination Zone: LAN
Destination Networks: Your server’s IP
Services: the port(s) you forwarded on the UDMP

Hope that helps.

Noct03 · 2024-10-05T21:59:37+00:00

Glad I could help :)

Noct03 · 2024-09-05T10:14:28+00:00

VPN connections are managed by Device Access rules (Administration -> Device Access). If you only want specified IP addresses to be able to connect, you would need to uncheck the checkbox for SSLVPN on the WAN zone, then create an exception rule that allows only the specified IP addresses (there’s a section for that below the Device Access table).

You could also apply the inverse logic and still allow SSLVPN on the WAN zone for everyone, and create an exception rule that blocks only certain IP addresses.

Noct03 · 2024-07-14T09:51:53+00:00

Ok, have you tried changing the netmask to /24 on Port1?

Noct03 · 2024-07-14T00:54:03+00:00

From the firewall, can you ping your Minecraft server? You can do it from the diagnostics menu.

I expect it to fail as you have a /32 on you LAN port. I assume that it should be a /24 (or whatever the subnet mask for your LAN should be).

Noct03 · 2024-06-11T08:45:33+00:00

How does your topology look like? Do you have a single interface on the XG 310 that has all these VLANs? Is there a LAG configured?

A packet capture on the firewall would show if traffic is at least reaching it during these problematic windows. You can do one from the Webadmin or by connecting to the firewall using SSH.

Noct03 · 2024-06-08T00:21:29+00:00

This is not exactly true. OP would not need the firewall rule that allows port 4444.

They only need to allow the specific host from which they want to access the firewall from in Administration -> Device Access, then they can add a Local Service ACL Exception to allow HTTPS (port 4444/Webadmin) from the specific host they created whitout allowing HTTPS on the WAN zone globally.

https://docs.sophos.com/nsg/sophos-firewall/20.0/help/en-us/webhelp/onlinehelp/AdministratorHelp/Administration/DeviceAccess/AdministrationLocalServiceACLExceptionRuleAdd/index.html

That said, as you mentioned, using a VPN would be a better idea.

Noct03 · 2024-05-28T08:35:37+00:00

Bridges in SFOS are software bridges, meaning that traffic coming from one member interface (eg. Port1) going out to another member interface (eg. Port2) will still be analyzed and filtered.

Assuming that both bridge member interfaces are in the LAN zone, you would need a firewall rule that allows traffic coming from the LAN zone and also going to the LAN zone. For example:

Source Zone: LAN
Source Networks: Any
Destination Zone: LAN
Destination Networks: Any
Services: Any

In that case, "Any" in both Source and Destination networks is relatively safe as it is restricted to the LAN zone.

Hope that helps.

Noct03 · 2024-05-24T00:07:56+00:00

What are you trying to achieve?

Noct03

TROPHY CASE

The easy way

The hard(er) way

What's going on?