Skip to main content
JimmyU
New Member
January 4, 2024
Question

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

  • January 4, 2024
  • 4 replies
  • 3903 views

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?

4 replies

AEK
SuperUser
SuperUser
January 4, 2024
  • 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
AEK
JimmyU
JimmyUAuthor
New Member
January 4, 2024

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
SuperUser
SuperUser
January 4, 2024

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.

AEK
ebilcari
Staff
Staff
January 4, 2024

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

Emirjon
ebilcari
Staff
Staff
January 4, 2024

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

Emirjon
sw2090
SuperUser
SuperUser
January 4, 2024

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.

ebilcari
Staff
Staff
January 4, 2024

It's within the same subnet, /25 will cover from 129 to 254.

Emirjon
sw2090
SuperUser
SuperUser
January 4, 2024

you're right in this case it is..