This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Can ping devices on VLAN from the gateway, can't access from the subnet on the main interface.

Hey there,

I set up two VLANs. VLAN 3 and VLAN 4. I can ping the gateway for both of the IPs, but can't ping all the IPs on them from the main subnet on the interface that the VLANs were created on. The difference is, the gateway and cisco switch everything is plugged into CAN ping those IPs. I'd really appreciate someone pointing me in the right direction here since I'm sure it's not a firewall rule issue since I tried making rules and checking firewall logs and didn't find anything.

Packet Trace:

Ethernet header

Source MAC address:

Destination MAC address:

Ethernet type IPv4 (0x800)

IPv4 Header

Source IP address:192.168.1.5

Destination IP address:192.168.4.193

Protocol: ICMP

Header:20 Bytes

Type of service: 0

Total length: 60 Bytes

Identification:15073

Fragment offset:0

Time to live: 127

Checksum: 31177

ICMP Header:

Type: 8

Code: 0

Echo ID: 1

Echo sequence: 951

Gateway: 0

Fragmentation MTU: 0

This thread was automatically locked due to age.

Parents

0 FormerMember over 4 years ago

Hi Gage C,

Thank you for reaching out to the Community!

Did you configure LAN to LAN firewall rule? If not, please configure LAN to LAN firewall rule.

If you already have the firewall rule and can't ping some devices in the network, check if any AV is configured to drop ICMP on the destination host.

You can also run a packet capture on the source IP address to see if any firewall rules drop this traffic or it is forwarded with the correct firewall rule id.

Check out the following KBA for more info: Monitor traffic using Packet Capture Utility in the Sophos XG Firewall GUI.

Thanks,
Cancel
Vote Up -1 Vote Down

Cancel
0 Gage C over 4 years ago in reply to FormerMember

I have created a LAN To LAN rule, and I ran a packet capture and it was correctly forwarding to the right interface. And it's the same result on multiple devices on the same subnet, so it's not anti-virus either. The rule ID equals a rule allowing the internet to connect to my DNS Server, so that's definitely not correct.
Cancel
Vote Up 0 Vote Down

Cancel
0 FormerMember over 4 years ago in reply to Gage C

Hi Gage C,

Thank you for providing screenshots.

You do not need the NAT rule for this traffic. In the screenshot of the packet capture, there is NAT ID 19. Could you please provide a screenshot of that NAT rule?

Thanks,
Cancel
Vote Up -1 Vote Down

Cancel
0 Gage C over 4 years ago in reply to FormerMember

It's a linked NAT rule for the LAN To LAN rule. I created it a long time ago; I actually forgot I did. Never the less, I've deleted the NAT rule.
Cancel
Vote Up 0 Vote Down

Cancel
0 FormerMember over 4 years ago in reply to Gage C

Hi Gage C,

Did it work after deleting the linked NAT rule?

Can you provide the screenshot of the packet capture?

Thanks,
Cancel
Vote Up -1 Vote Down

Cancel
0 Gage C over 4 years ago in reply to FormerMember

Nope, no change.
Cancel
Vote Up 0 Vote Down

Cancel
0 FormerMember over 4 years ago in reply to Gage C

Hi Gage C,

Can you show us some more packet entries for the same destination in the packet capture screenshot?

If we see traffic is forwarded via the correct interface and firewall rule, it could be blocked somewhere after leaving the firewall. It could be a Windows defender or any other AV installed on the destination workstation.

Thanks,
Cancel
Vote Up -1 Vote Down

Cancel
0 Gage C over 4 years ago in reply to FormerMember

What kind of packets, more to the inaccessible IPs, or to addresses I can access. It's on multiple devices, and the traffic only passes through the cisco switch, to the gateway, and back into the switch. And this a high availability proxy designed to provide load balancing for my Kubernetes cluster running on workload management. I can guarantee you that there is no firewall running on it.

Personally, I think it's some kind of routing issue.
Cancel
Vote Up 0 Vote Down

Cancel
0 Vicent A over 4 years ago in reply to Gage C

Hey Gage, How did this end ? I have a similar issue?
Cancel
Vote Up 0 Vote Down

Cancel
0 Gage C over 4 years ago in reply to Vicent A

Hey there, unfortunately I did not find a solution and am actively looking to replace my XG Firewall as a result of the issue. Let me know if you find more information about the issue then I did.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 Gage C over 4 years ago in reply to Vicent A

Hey there, unfortunately I did not find a solution and am actively looking to replace my XG Firewall as a result of the issue. Let me know if you find more information about the issue then I did.
Cancel
Vote Up 0 Vote Down

Cancel

Children

0 FormerMember over 4 years ago in reply to Gage C

Hello Gage C,

As per the packet capture snapshot the traffic is getting forwarded to destination IP 192.168.4.193 over Port1.4 interface, which is correct. But we couldn't see any reply packet.

====================================================

Request to follow the below steps:

==> Login to SSH > 4. Device Console and run below command.

console> tcpdump 'host <destination IP> and proto ICMP

example: console> tcpdump 'host 192.168.4.193 and proto ICMP

==> In another SSH session run below command to capture drops

console> drop-packet-capture 'host 192.168.4.193 and proto ICMP

==> Try to ping 192.168.4.193 from Port1 network(192.168.1.0/24) using below command in cmd and share session output here or via PM.

C:\Windows\system32>ping -n 2 192.168.4.193

====================================================

Please ensure that you have a reverse route added on L2/L3 switch towards XG for reply packets. If not you may try to apply the linked NAT rule with SNAT applied as MASQ on LAN to LAN firewall rule.

Before checking the reachability please flush all the connections for the destination IP from CLI.

console> system diagnostics utilities connections v4 delete dest_ip 192.168.4.193

Please feel free to reply to this thread or PM me if you've any queries.
Cancel
Vote Up 0 Vote Down

Cancel
0 Gage C over 4 years ago in reply to FormerMember

I reversed and deleted the kubernetes cluster to avoid using up valuable resources on something inaccessible, it'll take me an hour or two to set it back up. Other devices on the vlan do reply, it's just anything under the reverse proxy IP range that's unresponsive to the 192.168.1.0 subnet. If I put my device directly on the 192.168.4.0 subnet, everything begins to respond as normal though.
Cancel
Vote Up 0 Vote Down

Cancel