Virgin Media Community

[ravenstar68]

---

@用心棒 wrote:

---

@Vince68 wrote:

⋮
I have had a similar issue in the past which, apparently, was caused by the PS4 in the DMZ and resolved it by forwarding port 5353 to a high port 65535 on the Hub.

⋮

The solution proposed was to forward port 5353 to an unallocated IP address within your LAN, is that what you have done?

---

The solution depended on what the port forwarding mechanics would allow.  Where the hub allowed you to port forward asymmetrically e.g. port 80 -> device port 81.  I chose an existing device with a port of 65535 (which doesn't normally listen for inbound requests - hence the packet gets dropped)

Doing a quick check I believe the Nighthawk that Vince is using does allow the former.

If port forwarding can only be done symmetrically then I recommended forwarding the port to an IP address that wasn't being used.

However @Vince68 reports that when he tries to port forward he's getting conflict errors.

Vince what port forwarding rules are currently showing?

Can you walk us through EXACTLY how you are trying to set up the new rule?  Remember we can't see what you are doing here.

Tim

[ravenstar68]

---

@jem101 wrote:

However we can't really assume that third party routers behave in the same manner - for example the help page for the Asus RT-66 under DMZ, if you take their description at face value, seems to be saying that it forwards ALL unsolicited inbound traffic to the device which you specify as being in the DMZ. Now it could just be poorly worded, but it does sound that if you have a device in the DMZ, the Asus is simply going to ignore the port forward rules and simply forward everything there. It may be that other third-party routers do the same. Another possibility is that if a rule tries to forward traffic to an unresponsive host, then rather than dropping the packets, it forwards them to the DMZ device instead.   

---

Actually you'd hope all third party routers  behave consistently in certain respects.

When allowing traffic you'd normally expect the router to check the following:

1. Returning packet - send packet back to device in NAT table.
2. Unsolicited packet - Port Forwarding rule exists - send packet to device specified using Port Forwarding rule
3. Unsolicited packet - Device in DMZ - send packet to the DMZ device
4. Unsolicited packet - Drop the packet.

Certainly when I tested my Port forwarding rule with the Hub 3, it did do as I expected, i.e. with my PC in the DMZ the mDNS packets were no longer reaching port 5353 on my PC and Windows Firewall was quietly dropping the packet as there was nothing listening on the port the packet arrived at.

I would also remind all third party router owners to check to see if anyone else with their router has experienced anything similar mind you.

Tim

[jem101]

---

@ravenstar68 wrote:

---

@jem101 wrote:

However we can't really assume that third party routers behave in the same manner - for example the help page for the Asus RT-66 under DMZ, if you take their description at face value, seems to be saying that it forwards ALL unsolicited inbound traffic to the device which you specify as being in the DMZ. Now it could just be poorly worded, but it does sound that if you have a device in the DMZ, the Asus is simply going to ignore the port forward rules and simply forward everything there. It may be that other third-party routers do the same. Another possibility is that if a rule tries to forward traffic to an unresponsive host, then rather than dropping the packets, it forwards them to the DMZ device instead.   

---

Actually you'd hope all third party routers  behave consistently in certain respects.

snip...

---

Well yes, but I've been doing this for long enough to know that how you might expect a device to behave like is sometime (often?) not the way it actually does in the real world. I'm used to working with enterprise type firewalls and routers and their definitions of a DMZ has only a passing resemblance to what is called DMZ on domestic routers - so I really wouldn't rule anything out!

Anyhow I'm purely going on what some posters above have claimed, that putting an explicit port forward rule in their routers isn't working, and taking their claims at face value - just idle speculation really.

John

[Vince68]

@用心棒

I have not bee able to as stated in my post due to a port conflict 

[Vince68]

@Ravenstar68

I was simply following the previous advice of forwarding port 5353 to 65534 but I get the error Port conflict with other service.

Service name; MDNS

Service type: UDP

External starting port: 5353

External ending port 65535

Use the same port range for internal port: ticked

Internal IP address: PS4 IP address

As I said on the R7000 I was able to do it never received any emails from VM about MDNS vulnerability. I have not been able to set up the rule since switching to a R8000.