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.

[inkx27]

Sorry to resurrect this one again but I am on a third letter from VM regarding mDNS vulnerability.

I run a webserver with peronal cloud, pihole with recursive DNS (personal DNS server - this is NOT open to public only inside LAN), ssh, openvpn and media server etc. At the moment I have 80,443 (for web and openvpn - using port share option) and ssh port open which is not on 22, 53 or 5353. I also have a PS4 pro in DMZ and hence my interest in this thread and the responses. I also have upnp disabled.

So I have run exhaustive full port scans both on my Virgin IP, website and internal LAN network. From the outside world, 5353 is blocked and the only one open are the ones mentioned above and some ftp ones.

Having read the 5 pages of this thread there appears to be two solutions here.

1) create port forwarding rules for 5353 and 1900 and send them to an un-used ip so they get dumped.

2) find out which device is allowing mDNS which I guess I will need the report from ShadowServer or run more scans from the outside world to check which device is responding and then create port forward for the incoming 5353 and 1900 to a higher port number so they can be dropped.

At the moment I am considering using point 1 above and see if this stops the VM emails if not then I will go down the route of point 2.

Do you have guys generally agree this is the best way forward?

Thanks

V

[ravenstar68]

"I also have a PS4 pro in DMZ"

From checking with other users the PS4 in the DMZ is the issue here.  There's a Spotify mDNS responder that is active even if the Spotify app itself is not installed on the PS4, and it is this that responds to mDNS queries from external sources.  You can test this for yourself if you wish.

The Port Forwarding rule discussed will stop the external queries reaching your LAN while still allowing devices on the LAN itself to use mDNS

Tim 

[inkx27]

Interesting to hear that PS4 Pro has a spotify mDNS responder. Do you happen to know what ip address its using or even name of the server?

I will enable logging internally to find out the culprit address and block it. May be that might be a way forward if all queries generating from PS4 Pro Spotify are blocked rather than allowed to go out.

[inkx27]

I will run some further tests tomorrow with logging enabled to see what ps4 is doing for mdns requests. 

In the meantime, would you say I should go for option 1 or option 2 as per my post above. 

That is to forward port 5353 to an unused ip address or use the ps4 pro ip and forward them to a higher port on ps4. 

[ravenstar68]

I think you misunderstand what's happening.

Any unsolicited incoming traffic not covered by a specific port forwarding rule is forwarded to the device in the DMZ if there is one, otherwise it is dropped.

So the PS4 isn't generating a query, instead there's a query being sent to your public IP address and the hub is doing what you've asked it to and sending the query to your PS4 which is then sending back a response.

Now assuming you pick up a query from Shadowserver and block their address, that would stop the letters from Virgin Media, BUT it would still leave your PS4 open to being used to take part in a DDOS attack, as mDNS queries from other external IP addresses would still get through.

This is why I developed the strategy of port forwarding port 5353 to either an unused port or an unused IP address.  You effectively filter all inbound mDNS queries that would otherwise be sent to your PS4 no matter what IP address they arrive from.

Tim