1

I have the following network setup https://i.ibb.co/wwPLH2H/Network.png

All traffic from 10.0.64.0 / 27 behind FirewallB (firewallsm) reaches 192.168.28.0 / 27 network via the LAN interface of FirewallA (firewallwm), and the same traffic also reaches internet in the same way, as follows:

10.0.64.42 (VM) > FirewallB (LAN) > FirewallA (LAN) > FirewallA (WAN) > Laptop's Wireless NIC > Wifi Router

Strangely FirewallB (firewallsm) can ping Google DNS but the VM 10.0.64.42 for some reason cannot ping Google DNS. I have set all protocols, ports as allowed on FirewallB (firewallsm) to reach FirewallA (firewallwm).

FirewallA (firewallwm)

Gateway - https://i.ibb.co/bRC8P8G/Firewall-A-GW.png

LAN Interface Rule - https://i.ibb.co/XWSnLRd/Firewall-A-1-dell-Rule.png

WAN Interface Rule - https://i.ibb.co/zZwcnjJ/Firewall-A-2-WAN-Rule.png

FirewallA (firewallsm) logs show 10.0.64.42 traffic is allowed through its WAN

Log - https://i.ibb.co/9cqPSW7/Firewall-A-Packet-log.png

Log - https://i.ibb.co/kVTX31B/Firewall-A-Packet-log-2.png

FirewallB (firewallsm)

Gateway - https://i.ibb.co/pPQC1p8/Firewall-B-GW.png

LAN Rule - https://i.ibb.co/VY9vFVL/Firewall-B-1-dell-Rule.png

tcpdump for 10.0.64.42 VM on FirewallB LAN (em0)

root@firewallsm:~ # tcpdump -i vmx0 host 10.0.64.42 and host 8.8.8.8 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmx0, link-type EN10MB (Ethernet), capture size 262144 bytes
06:17:09.324409 IP 10.0.64.42 > dns.google: ICMP echo request, id 1, seq 1, length 40
06:17:13.853917 IP 10.0.64.42 > dns.google: ICMP echo request, id 1, seq 2, length 40
06:17:18.858484 IP 10.0.64.42 > dns.google: ICMP echo request, id 1, seq 3, length 40

tcpdump for 10.0.64.42 VM on FirewallA LAN (em0)

root@firewallwm:~ # tcpdump -i em0 host 8.8.8.8 and icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes
06:17:09.335331 IP 10.0.64.42 > 8.8.8.8: ICMP echo request, id 1, seq 1, length 40
06:17:13.865408 IP 10.0.64.42 > 8.8.8.8: ICMP echo request, id 1, seq 2, length 40
06:17:23.870819 IP 10.0.64.42 > 8.8.8.8: ICMP echo request, id 1, seq 4, length 40

tcpdump for 10.0.64.42 VM on FirewallA WAN (em1)

root@firewallwm:~ # tcpdump -i em1 host 8.8.8.8 and icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 262144 bytes

Ping from FirewallB successful in pinging Google DNS

root@firewallsm:~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=127 time=13.196 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=127 time=12.625 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=127 time=12.609 ms
^C
--- 8.8.8.8 ping statistics ---
16 packets transmitted, 16 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.705/13.026/15.910/1.111 ms

tcpdump of FirewallA LAN (em0)

root@firewallwm:~ # tcpdump -i em0 host 8.8.8.8 and icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes
06:22:21.816908 IP 192.168.10.7 > 8.8.8.8: ICMP echo request, id 23594, seq 0, length 64
06:22:21.827095 IP 8.8.8.8 > 192.168.10.7: ICMP echo reply, id 23594, seq 0, length 64
06:22:22.876598 IP 192.168.10.7 > 8.8.8.8: ICMP echo request, id 23594, seq 1, length 64
06:22:22.886317 IP 8.8.8.8 > 192.168.10.7: ICMP echo reply, id 23594, seq 1, length 64
06:22:23.948947 IP 192.168.10.7 > 8.8.8.8: ICMP echo request, id 23594, seq 2, length 64
06:22:23.957978 IP 8.8.8.8 > 192.168.10.7: ICMP echo reply, id 23594, seq 2, length 64

tcpdump of FirewallA WAN (em1)

root@firewallwm:~ # tcpdump -i em1 host 8.8.8.8 and icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 262144 bytes
06:22:21.817029 IP 192.168.47.132 > 8.8.8.8: ICMP echo request, id 24689, seq 0, length 64
06:22:21.826993 IP 8.8.8.8 > 192.168.47.132: ICMP echo reply, id 24689, seq 0, length 64
06:22:22.876700 IP 192.168.47.132 > 8.8.8.8: ICMP echo request, id 24689, seq 1, length 64
06:22:22.886219 IP 8.8.8.8 > 192.168.47.132: ICMP echo reply, id 24689, seq 1, length 64
06:22:23.949057 IP 192.168.47.132 > 8.8.8.8: ICMP echo request, id 24689, seq 2, length 64
06:22:23.957845 IP 8.8.8.8 > 192.168.47.132: ICMP echo reply, id 24689, seq 2, length 64
5
  • I had a similar issue some time ago. The firewall of the Windows-VM could be blocking the echo-replies.
    – ecisse
    Commented Mar 4, 2021 at 22:50
  • Welcome! I don't see a security question here; voting to move. Commented Mar 4, 2021 at 23:14
  • If this were the case, I would expect the firewallX tcpdump logs (in the first section) to show the ICMP packets returning from 8.8.8.8 (as they do when ping is issued from FirewallB) .. (I also checked whether tcpdump .. host and host .. syntax might have been inadvertantly excluding return packets- it's not). I wonder if the configuration of Firewall A is refusing to accept return packets destined for the internal VM subnet?
    – brynk
    Commented Mar 4, 2021 at 23:28
  • ecisse - I would doubt that as I can ping and receive replies from 192.168.28.40 Server. brynk - I'm not sure about that as Firewall B receives replies from 8.8.8.8 through FirewallA, and traffic from Windows-VM is also going through the same route as Firewall B
    – Huud Rych
    Commented Mar 5, 2021 at 6:08
  • @HuudRych A general FYI: markdown formatting makes a huge difference in the ease of readability of long[er] questions/answers, especially bulleted/numerical lists as they tie together points applicable to the sentence/paragraph above them. Weblink markdown is recommended since it's more efficient, both on the reader and in regards to space _(pictures can also be inlined, either via the Media attach button or by using weblink markdown placing an ! in front of the link's [
    – JW0914
    Commented Mar 5, 2021 at 15:10

0

You must log in to answer this question.

Browse other questions tagged .