Firewall logs show query replied back to mdns

[tryllz]

Hi,

This setup is in VMware Workstation.

I have setup a Windows Server VM (192.168.28.47 / 27) with no internet access, I have setup a firewall rule to allow access to internet over port 1688 for activation only. The rule does not seem to be working for some reason, I have allowed ping and the server receives replies from 8.8.8.8. the NAT interface is 192.168.47.140, and NAT gateway is 192.168.47.2. I disabled the firewall and tested, the server activation works.

On the WAN interface all traffic is allowed.

Ping - https://i.ibb.co/pbfxMff/Ping.png
Rule - https://i.ibb.co/fG2yRrN/Rules.png
Firewall Log - https://i.ibb.co/1Xxx4KX/Block.png
NAT - https://i.ibb.co/6wyRK0w/NAT.png

tcpdump on WAN interface

Code: [Select]

root@firewallwm:~ # tcpdump -i em1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 262144 bytes
08:16:39.501781 IP 192.168.47.1.59200 > 239.255.255.250.1900: UDP, length 173
08:16:40.503212 IP 192.168.47.1.59200 > 239.255.255.250.1900: UDP, length 173
08:16:41.505361 IP 192.168.47.1.59200 > 239.255.255.250.1900: UDP, length 173
08:16:42.509410 IP 192.168.47.1.59200 > 239.255.255.250.1900: UDP, length 173
08:16:54.790178 IP firewallwm.vlab.lab.33761 > dns.google.domain: 15413+ A? google.com. (28)
08:16:54.790822 IP firewallwm.vlab.lab.8231 > b.in-addr-servers.arpa.domain: 11474% [1au] A? 8.in-addr.arpa. (43)
08:16:54.803744 ARP, Request who-has firewallwm.vlab.lab tell 192.168.47.2, length 46
08:16:54.803770 ARP, Reply firewallwm.vlab.lab is-at 00:0c:29:e8:8d:15 (oui Unknown), length 28
08:16:54.803961 IP dns.google.domain > firewallwm.vlab.lab.33761: 15413 6/0/0 A 74.125.193.139, A 74.125.193.101, A 74.125.193.102, A 74.125.193.138, A 74.125.193.113, A 74.125.193.100 (124)
08:16:54.834659 IP b.in-addr-servers.arpa.domain > firewallwm.vlab.lab.8231: 11474- 0/9/1 (419)
08:16:54.834905 IP firewallwm.vlab.lab.43612 > arin.authdns.ripe.net.domain: 12959% [1au] A? 8.8.in-addr.arpa. (45)
08:16:54.851866 IP arin.authdns.ripe.net.domain > firewallwm.vlab.lab.43612: 12959- 0/4/1 (304)
08:16:54.852243 IP firewallwm.vlab.lab.9190 > l.gtld-servers.net.domain: 34242% [1au] A? level3.net. (39)
08:16:54.852414 IP firewallwm.vlab.lab.41556 > m.gtld-servers.net.domain: 60361% [1au] A? level3.net. (39)
08:16:54.887227 IP l.gtld-servers.net.domain > firewallwm.vlab.lab.9190: 34242- 0/6/3 (659)
08:16:54.887443 IP m.gtld-servers.net.domain > firewallwm.vlab.lab.41556: 60361- 0/6/3 (659)
08:16:54.887528 IP firewallwm.vlab.lab.61168 > ns1.level3.net.domain: 6148% [1au] A? ns2.level3.net. (43)
08:16:54.887690 IP firewallwm.vlab.lab.64640 > ns1.level3.net.domain: 16450% [1au] A? ns1.level3.net. (43)
08:16:54.971955 IP ns1.level3.net.domain > firewallwm.vlab.lab.61168: 6148*- 1/0/1 A 209.244.0.2 (70)
08:16:54.972141 IP firewallwm.vlab.lab.26125 > ns2.level3.net.domain: 3609% [1au] A? 8.8.8.in-addr.arpa. (47)
08:16:54.975305 IP ns1.level3.net.domain > firewallwm.vlab.lab.64640: 16450*- 1/0/1 A 209.244.0.1 (70)
08:16:55.057760 IP ns2.level3.net.domain > firewallwm.vlab.lab.26125: 3609- 0/4/1 (129)

[banym]

Well I think you need more than just one port for the activiation. But I am not an expert on that.

I would create a rule to allow any traffic and then sniff what is needed.
I expect you need DNS, maybe some HTTPS or HTTP calls and maybe some more detailed ports for the activation.

Have fun.

[tryllz]

Well I think you need more than just one port for the activiation. But I am not an expert on that.

I would create a rule to allow any traffic and then sniff what is needed.
I expect you need DNS, maybe some HTTPS or HTTP calls and maybe some more detailed ports for the activation.

Have fun.

Thanks for clarifying, I believe I misunderstood read about it being just port 1688.

I better sniff and see whats traversing..

[tryllz]

I ran tcpdump on both LAN and WAN all interfaces, strangely the LAN interfaces has traffic flowing and is receiving replies from 8.8.8.8 but nothing is showing up on the WAN interface.

tcpdump on LAN for Server VM

Code: [Select]

root@firewallwm:~ # tcpdump -i em3 host 192.168.28.47
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em3, link-type EN10MB (Ethernet), capture size 262144 bytes
17:37:05.247138 IP 192.168.28.47 > dns.google: ICMP echo request, id 1, seq 54, length 40
17:37:05.260352 IP dns.google > 192.168.28.47: ICMP echo reply, id 1, seq 54, length 40
17:37:06.269572 IP 192.168.28.47 > dns.google: ICMP echo request, id 1, seq 55, length 40
17:37:06.283080 IP dns.google > 192.168.28.47: ICMP echo reply, id 1, seq 55, length 40
17:37:07.289858 IP 192.168.28.47 > dns.google: ICMP echo request, id 1, seq 56, length 40
17:37:07.298693 IP dns.google > 192.168.28.47: ICMP echo reply, id 1, seq 56, length 40
17:37:08.302397 IP 192.168.28.47 > dns.google: ICMP echo request, id 1, seq 57, length 40
17:37:08.311143 IP dns.google > 192.168.28.47: ICMP echo reply, id 1, seq 57, length 40
17:37:09.866366 ARP, Request who-has firewallwm.vlab.lab (00:0c:29:e8:8d:29 (oui Unknown)) tell 192.168.28.47, length 46
17:37:09.866397 ARP, Reply firewallwm.vlab.lab is-at 00:0c:29:e8:8d:29 (oui Unknown), length 28
17:37:36.493211 IP 192.168.28.47.60468 > 239.255.255.250.1900: UDP, length 173
17:37:37.509653 IP 192.168.28.47.60468 > 239.255.255.250.1900: UDP, length 173
17:37:38.523971 IP 192.168.28.47.60468 > 239.255.255.250.1900: UDP, length 173
17:37:39.540750 IP 192.168.28.47.60468 > 239.255.255.250.1900: UDP, length 173
17:39:36.498026 IP 192.168.28.47.60469 > 239.255.255.250.1900: UDP, length 173
17:39:37.510526 IP 192.168.28.47.60469 > 239.255.255.250.1900: UDP, length 173
17:39:38.512683 IP 192.168.28.47.60469 > 239.255.255.250.1900: UDP, length 173
17:39:39.512937 IP 192.168.28.47.60469 > 239.255.255.250.1900: UDP, length 173
17:39:53.018203 IP 192.168.28.47.netbios-ns > 192.168.28.63.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:39:53.027039 IP 192.168.28.47.mdns > 224.0.0.251.mdns: 0 A (QM)? google.local. (30)
17:39:53.032230 IP 192.168.28.47.mdns > 224.0.0.251.mdns: 0 AAAA (QM)? google.local. (30)
17:39:53.033009 IP 192.168.28.47.56963 > 224.0.0.252.5355: UDP, length 24
17:39:53.040405 IP 192.168.28.47.62251 > 224.0.0.252.5355: UDP, length 24
17:39:53.445140 IP 192.168.28.47.56963 > 224.0.0.252.5355: UDP, length 24
17:39:53.460646 IP 192.168.28.47.62251 > 224.0.0.252.5355: UDP, length 24
17:39:53.771373 IP 192.168.28.47.netbios-ns > 192.168.28.63.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:39:54.038374 IP 192.168.28.47.mdns > 224.0.0.251.mdns: 0 A (QM)? google.local. (30)
17:39:54.039114 IP 192.168.28.47.mdns > 224.0.0.251.mdns: 0 AAAA (QM)? google.local. (30)
17:39:54.536041 IP 192.168.28.47.netbios-ns > 192.168.28.63.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
tcpdump on WAN for Server VM

Code: [Select]

root@firewallwm:~ # tcpdump -i em0 host 192.168.28.47
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump on WAN without any host

Code: [Select]

root@firewallwm:~ # tcpdump -i em1 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 262144 bytes
17:53:05.670752 IP 192.168.47.140.27089 > 188.165.3.28.123: NTPv4, Client, length 48
17:53:07.652383 IP 192.168.47.140.10811 > 188.125.64.7.123: NTPv4, Client, length 48
17:53:07.673695 IP 188.125.64.7.123 > 192.168.47.140.10811: NTPv4, Server, length 48
17:53:08.624653 IP 192.168.47.140.28314 > 91.209.0.17.123: NTPv4, Client, length 48
17:53:08.672014 IP 91.209.0.17.123 > 192.168.47.140.28314: NTPv4, Server, length 48
17:53:09.680357 IP 192.168.47.140.44852 > 80.237.128.148.123: NTPv4, Client, length 48
17:53:09.680434 IP 192.168.47.140.58287 > 162.159.200.123.123: NTPv4, Client, length 48
17:53:09.698470 IP 162.159.200.123.123 > 192.168.47.140.58287: NTPv4, Server, length 48
17:53:09.720681 IP 80.237.128.148.123 > 192.168.47.140.44852: NTPv4, Server, length 48
17:53:12.633164 IP 192.168.47.140.59261 > 94.199.173.123.123: NTPv4, Client, length 48
17:53:12.671315 IP 94.199.173.123.123 > 192.168.47.140.59261: NTPv4, Server, length 48
17:53:54.738729 IP6 fe80::20c:29ff:fee8:8d15.546 > ff02::1:2.547: dhcp6 solicit
17:58:48.516746 IP 192.168.47.1.64045 > 239.255.255.250.1900: UDP, length 173
17:58:49.517887 IP 192.168.47.1.64045 > 239.255.255.250.1900: UDP, length 173
17:58:50.520981 IP 192.168.47.1.64045 > 239.255.255.250.1900: UDP, length 173
17:58:51.522420 IP 192.168.47.1.64045 > 239.255.255.250.1900: UDP, length 173
Sorry couldn't make much sense of the replies but the server queries are going to 224.0.0.251 which I read is Multicast DNS. As I understand the packets are not being forwarded to the WAN interface.

Thus 2 questions, 1) How are ping replies coming from Google's DNS ?!, and 2) why aren't the packets are not reaching the WAN interface.

I applied an All-Traffic-Allowed rule on the Server VM interface, the replies are still the same which is confusing me.