With other firewall vendors (i.e. Cisco) you can ping any interface you are ‘directly connected to‘. With Fortigate however you cannot (by default). That’s not the end of the world you can check connectivity using ARP (see below) which is what really cool network techs do instead! But if you want to be able to ping an interface (even for a short period of time). Here’s how to do it.
Solution
Fundamentally, the reason you can’t ping a Fortigate interface, is because ‘ping’ isn’t listed in the ‘allowaccess‘ section for that interface.
Let’s fix that;
[box]
config system interface
edit {port-name}
set allowances {Existing settings i.e. https http etc.} ping
end
[/box]
Using ARP to check connectivity
A lot of people assume that if you can’t ping something, you are not connected to it, that’s not the case at all. If you ‘think’ something is on the same layer 2 network segment as you, and you can’t ping it, then look in the ARP cache on your machine, (for Windows and Linux the command is arp -a).
Below: Shows you can see the MAC address of that IP address, even if you cannot receive a ping response!
However once ping is enabled, your ICMP responses will work fine.
Related Articles, References, Credits, or External Links
I had a client machine struggling to get an DHCP address, and when I looked in DHCP the scope it was full of this;
BAD_ADDRESS This address Is Already in Use
Solution
A tour of Google and forums is full of posts by people with this problem, and other than, ‘Oh I looked in the logs and fixed it’ (with no mention of what log, or where this log was), or ‘Yeah I used Wireshark and located a problem client‘, then no follow up on what they did, or scanned for. So I pretty much had to slog through and work it out for myself. I’ll detail each step I took below, most of which didn’t help, or sent me in the wrong direction, but for you that may be a better solution.
And I will give you enough information to at least be helpful!
Firstly Common Sense Check: If this has just happened what have you changed? Have you added any Wireless Controllers, or Access Points? Have you deployed any new Switches or Firewalls. In my case, it was my test network so it could have been happening for months!
The most frequent cause of this error is simply because someone has setup another DHCP server on the network. That will be easy to diagnose, simply ‘Stop’ your DHCP Server;
Then on a DHCP client, issue an ifconfig /release and ifconfig /renew, If it gets an IP address, issue an ifconfig /all and look for the IP of the DHCP server it’s using, that’s your culprit. However as you can see, mine didn’t get an IP address so this wasn’t my problem.
The next most popular suggestion is to enable ‘Conflict Detection‘, though in most places the information on where to find this, is incorrect, (as it’s been copied and pasted around the forums without actually checking it!) See below, you locate it on the properties of the Protocol not the Server > Advanced Tab > You are supposed to set it between 1 and 6 so I went for 5, (but after deleting all the BAD_ADDRESS entries, they were all back after 30 minutes or so, so this didn’t work for me either).
Look in the logs: Well they were useless also, DHCP creates a new log every day in C:\Windows\System32\Dhcp called ‘DHCPSrvLog-DAY.log’ as you can see it was not helpful.
At this point I put my networking head on, and ‘thought outside the box’, If DHCP is detecting these as BAD ADDRESSES, then they must be in the arp cache on the DHCP server right? Well look at this;
[box]
arp -a
[/box]
Well that’s encouraging, at least now I’ve got a suspect MAC address, lookup up that MAC address online, and it comes back as VMWare (which sent me off in the wrong direction, it was not a VMware virtual machine in my vSphere in the end). Ive got a decent Cisco Switch so I thought I’d see which interface it was connected to, (but it wasn’t there).
[box]
show mac address-table
[/box]
At this point I was still thinking it was a VMware virtual machine, so I used PowerCLI (Thats PowerShell for VMware), to query for that MAC address, but that revealed nothing.
So, my last hope was Wireshark, I fired it up on the DHCP server, and set the filter to;
[box]
bootp.option.type == 53
[/box]
Then I deleted all the BAD_ADDRESS entries, left Wireshark ‘sniffing’, and went for lunch. I returned to this (see below). Now 192,168,100,107 was one of the BAD_ADDRESS entries, and I did not know what it was. The other entries on there for 192.168.100.3 are understandable, (that’s my DHCP server!) So now I had a Layer 3 address to hunt.
When I RDP connected to it, I got prompted for a password, so now I know it’s a Windows box! I hunted all through my VMware virtual machines, it was not there. Just as an afterthought I remembered I have a Hyper-V server, could that be running a virtual machine? BOOM! There is a SCVMM server, I was using for some Zerto testing a couple of months ago! Turned it off, problem solved!
Hope you find your culprit quicker than I did!
Related Articles, References, Credits, or External Links
I use EVE-NG a lot, it’s an awesome tool. Also I’m lucky enough to have my own ESX servers, so that’s where it lives. I’ve noticed this problem before, but I’ve either given up, and done something else, or it’s manifested itself in an ‘odd’ way that I can work around.
If you’re new to connecting EVE-NG to a live network you might want to read the following post first;
When setting up a new lab, I connected a Ciso IOL router to my cloud object, and it successfully got an IP from DHCP, but could not communicate with the outside world. So I replaced it with a Cisco (Dynamips) router, same thing! So I replaced with with a Cisco ASAv, same thing!
I moved the EVE-NG machine onto its own standard vSwitch, (no difference).
I hadn’t committed the ‘schoolboy error‘ of forgetting to allow promiscuous mode on the port group.
I could also see from my physical network, that there was layer 2 connectivity happening, as it was in in the ARP cache of my core switch.
I did notice that if I waited for a long time, it would start working, so (on the Core Switch) I flushed the ARP cache, and pinged the EVE-NG device and got a response, then it worked fine from EVE-NG, (for a while, in a manner of speaking!) If I tried to NAT any other traffic, or do anything else, then the problem returned. I could keep flushing the ARP cache on the switch, but that’s a bit annoying?
Solution
Well, (in my case) the problem turned out to be a problem with the fact I have ‘teamed‘ physical NICs on the vSwitch, which you can see above (vmnic0, and vmnic7). AS SOON as I removed one, and only had one physical uplink it worked faultlessly?
Everything works now.
Note: I tried changing the load balancing algorithms to ‘Route based on IP hash‘, ‘Route based on source MAC hash, and even ‘Use Explicit failover order‘, none of these worked.
I did see other people in forums that were saying, ‘I only have one physical uplink‘, I’m suspecting that in their case, it’s promiscuous mode was missing, but feel free to comment below, if any one manages a better work-around / fix / explanation.
Related Articles, References, Credits, or External Links
This is a strange one? I was deploying FirePOWER to a pair of ASA 5550-8-X firewalls in Active / Standby failover last week. After each SFR was updated (via ASDM.) I could no longer ‘ping it’, the SFR itself could ping everything on the same VLAN, APART from its own default gateway, (which was an SVI on the Cisco 3750 switch it was connected to).
This happened every time I updated the SFR, (or re-imaged it.) Then after an hour or so it was fine?
Solution
If I connected to the switch that the SFR, (and firewall) was connected to, I could NOT ping the SFR. The interface was up/up on the switch, and the firewalls Management interface was also up/up.
[box]
Petes-3750#ping 10.2.1.252
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.1.252, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
[/box]
I did notice it was in the ARP table though, (with the correct MAC address), So I manually removed it;
[box]
Petes-3750#clear ip arp 10.2.1.252
[/box]
Then it was fine?
[box]
Petes-3750#ping 10.2.1.252
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.1.252, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
After not touching one for a couple of years, I was back on HP switches recently, and I had to map out a clients switches. Now I could have used some software, but they didn’t have SNMP enabled so, I had to ‘re acquaint’ myself with LLDP.
For a More Detailed LLDP View of attached devices.
Note: This command will NOT show up in the help menu!
[box]
HP-Switch-1# show lldp info remote all
LLDP Remote Device Information Detail
Local Port : 10
ChassisType : local
ChassisId : Cisco1.petenetlive.com
PortType : local
PortId : GigabitEthernet0/15
SysName :
System Descr : Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Ver...
PortDescr :
System Capabilities Supported : bridge
System Capabilities Enabled : bridge
Remote Management Address
Type : ipv4
Address : 111.222.111.222
------------------------------------------------------------------------------
Local Port : 10
ChassisType : mac-address
ChassisId : 00 1c f6 c8 55 8f
PortType : inte...
PortId : || PeteNet || 10Mb ||...
SysName : Cisco1.petenetlive.com
System Descr : Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Ver...
PortDescr : GigabitEthernet0/15
System Capabilities Supported : bridge, router
System Capabilities Enabled :
Remote Management Address
Type : ipv4
Address : 111.222.111.222
------------------------------------------------------------------------------
Local Port : 13
ChassisType : local
ChassisId : Cisco1.petenetlive.com
PortType : local
PortId : GigabitEthernet0/18
SysName :
System Descr : Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Ver...
PortDescr :
System Capabilities Supported : bridge
System Capabilities Enabled : bridge
Remote Management Address
Type : ipv4
Address : 111.222.111.222
------------------------------------------------------------------------------
Local Port : 13
ChassisType : mac-address
ChassisId : 00 1c f6 c8 55 92
PortType : inte...
PortId : || PeteNet || Previou...
SysName : Cisco1.petenetlive.com
System Descr : Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Ver...
PortDescr : GigabitEthernet0/18
System Capabilities Supported : bridge, router
System Capabilities Enabled :
Remote Management Address
Type : ipv4
Address : 111.222.111.222
------------------------------------------------------------------------------
Local Port : 23
ChassisType : mac-address
ChassisId : c0 91 34 dd 3b c0
PortType : local
PortId : 23
SysName : HP-Switch-2
System Descr : HP J9145A 2910al-24G Switch, revision W.15.13.0014, ROM W...
PortDescr : 23
System Capabilities Supported : bridge, router
System Capabilities Enabled : bridge, router
Remote Management Address
Type : ipv4
Address : 192.168.1.221
Poe Plus Information Detail
Poe Device Type : Type2 PSE
Power Source : Unknown
Power Priority : Unknown
Requested Power Value : 0 Watts
Actual Power Value : 0 Watts
------------------------------------------------------------------------------
Local Port : 24
ChassisType : mac-address
ChassisId : c0 91 34 dd 3b c0
PortType : local
PortId : 24
SysName : HP-Switch-2
System Descr : HP J9145A 2910al-24G Switch, revision W.15.13.0014, ROM W...
PortDescr : 24
System Capabilities Supported : bridge, router
System Capabilities Enabled : bridge, router
Remote Management Address
Type : ipv4
Address : 192.168.1.221
Poe Plus Information Detail
Poe Device Type : Type2 PSE
Power Source : Unknown
Power Priority : Unknown
Requested Power Value : 0 Watts
Actual Power Value : 0 Watts
[/box]
To find what Port an IP address is on
First ping the IP address, to make sure that the switch has the MAC address you are looking at, in its ARP cache.
[box]
HP-Switch-1# ping 192.168.251.2
192.168.251.2 is alive, time = 3 ms
[/box]
Then look for it in the ARP cache;
[box]
HP-Switch-1# show arp
IP ARP table
IP Address MAC Address Type Port
--------------- ----------------- ------- ----
192.168.251.1 e8b748-c757b0 dynamic 13
192.168.251.2 005056-a61c1c dynamic 5 << It’s on port 5
192.168.251.5 005056-a606d9 dynamic 7
[/box]
Or if you already know its MAC address;
[box]
HP-Switch-1# show mac-address 005056-a61c1c
Status and Counters - Address Table - 005056-a61c1c
Port
-------
5
[/box]
Related Articles, References, Credits, or External Links
My colleague was setting up a DMZ server for one of our clients, it was a virtual server that was presented to the DMZ of a Cisco ASA 5510. Every time he gave it a static IP address it popped up an IP address conflict (no matter what the IP address was).
Windows has detected an IP address conflict
Another computer on this network has the same IP address as this computer. Contact your network administrator for help resolving this issue. More details are available in the Windows event log.
He asked me to set up DHCP for the DMZ to see if that would cure the problem, which I did. However that also refused to work either.
Windows IP Configuration
An error occurred while renewing interface Local Area Connection : The DHCP client has obtained an IP address that is already in use on the network. The local interface will be disabled until the DHCP client can obtain a new address.
An error occurred while releasing interface. Loopback Pseudo-Interface 1 : The system cannot find the file specified.
Solution
Turns out this is a known problem, and is pretty easy to rectify.
Option 1 (On the ASA)
1. Connect to the ASA via command line, log in and then go to enable mode
[box]
Password:******
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
[/box]
2. Enter configure terminal mode then disable proxy ARP on the interface that’s presented to the problem network, (in this case the interface is called DMZ).
PetesASA# >write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d
7424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesASA#
[/box] Note: You can also disable proxy arp in the nat tranlation, with the no-proxy-arp like so; [box] PetesASA(config)# nat (inside,DMZ) source static Inside-LAN Inside-LAN destination static Inside-LAN Inside-LAN no-proxy-arp [/box]
Option 2 (On the affected machine)
Note: This is is for Windows based clients. 1. Start > Run > regedit {Enter}. 2. Navigate to;
