Cannot connect to another companys webserver on same ISP and IP network as the WAN interface

[JimmyU]

I have a customer with a Fortigate 40F (v7.0.12) where the WAN interface is connected to their ISP and configured with x.y.z.180/25 where 181 and 182 are secondary IPs.
x.y.z.129 is configured as the ISP default gateway and everything seems to be working normally.

However when trying to connect to another companys webserver (x.y.z.208) that uses the same ISP and is on the same IP net I cannot connect to it or ping it.

Running a traceroute in the Fortigate CLI shows somethng like this
traceroute to x.y.z.208 (x.y.z.208), 32 hops max, 3 probe packets per hop, 84 byte packets
1 x.y.z.129 (gw.isp.com) 0.533 ms 0.250 ms 1.430 ms
2 x.y.70.209 2.018 ms 2.284 ms 1.283 ms
3 x.y.78.133 5.528 ms 1.932 ms 1.452 ms
4 * * *
5 x.y.78.70 1.674 ms 1.581 ms 1.288 ms
6 x.y.72.123 0.345 ms 0.348 ms 0.313 ms
7 x.y.76.250 0.342 ms 0.371 ms 0.330 ms
8 * * *
9 * * *
10 * * *

I expected it to try and communicate with the server directly and not go through the gateway since they are on the same IP net, is this expected behavior?

Anybody have any guesses as to what is going on? Something in the firewall, the ISP or both?

[AEK]

• You second company may just have disabled ping and http(s) access
• You second company may have configured a firewall policy that denies your IP from connecting to his server

[JimmyU]

The second company is completely separate from my customer and they work with profile clothing and the webshop is available as long as you connect from any other network.
So that the ping doesn't work isn't supprising but https traffic should be let through.

[AEK]

Do you have access to fgt of second company? If so, check if he is using the right netmask for his wan IP. In case he used /24 by mistake then the symptom would be similar as the one you have now.

[JimmyU]

No, I have no access to the other companys equipment

[ebilcari]

If they share the same subnet, the IP should be reachable directly without routing.

Keep in mind that ISP offer services based on overlay protocols like MPLS or pseudo wire and even though the IP are part of the same subnet the ARP will not work between the nodes, so sometimes the communication is not possible. First thing I would suggest to talk with the ISP and ask why it's not reachable.

If you check the routing table in FGT, do you see the subnet listed as directly connected?

GW # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
* - candidate default

Routing table for VRF=0

C 10.0.0.0/24 is directly connected, port2

is the IP present in the ARP table?

GW # get system arp
Address Age(min) Hardware Addr Interface
10.0.0.2 0 00:15:5d:00:00:05 port2

[ebilcari]

and since you are getting the reply from the IP of the next hop (ISP) it looks like some proxy ARP is implemented by them: x.y.z.129 (gw.isp.com) 0.533 ms 0.250 ms 1.430 ms

[JimmyU]

Checking the routing table this entry is there
C x.y.z.128/25 is directly attached, wan

If I ping x.y.z.129 and x.y.z.208 they are both in the ARP table with the same hardware address so I guess there may be some ISP trickery.

Thanks for the info, I have registered a ticket with them so will see what their response is.

[ebilcari]

If they share the same MAC address for both public IPs (next-hop and the IP you want to reach) than ARP proxy is implemented by them.

[sw2090]

As you say you are part of a /25 subnet on your wan it could also be that .208 is in the same class B (or even class C) subnet but not in that /25. In this case it would be totally correct that traffic hits the default route.