Ever work on a Fortigate and need to show the IP addresses quickly – especially if the interfaces are DHCP? Try this via CLI
#show system interface ?
name name
IPSEC-VIFace static 0.0.0.0 0.0.0.0 up disable tunnel
dmz static 0.0.0.0 0.0.0.0 up disable physical
internal static 10.100.10.1 255.255.255.0 up disable physical
modem static 0.0.0.0 0.0.0.0 down disable physical
ssl.root static 0.0.0.0 0.0.0.0 up disable tunnel
wan1 static xxx.xxx.xxx.222 255.255.255.224 up disable physical
wan2 static 0.0.0.0 0.0.0.0 up disable physical
Using VDOM’s? You’ll need to enter the following per VDOM:
#config vdom
#edit VDOMNAME
#show system interface ?
Done!
I have worked with SonicWall’s in the past, one feature I am spoiled using is something Cisco calls an Extended Ping – per Cisco’s site
The Extended ping Command
When a normal ping command is sent from a router, the source address of the ping is the IP address of the interface that the packet uses to exit the router. If an extended ping command is used, the source IP address can be changed to any IP address on the router. The extended ping is used to perform a more advanced check of host reach-ability and network connectivity.
It appears SonicWall does not have a feature like this in their OS? I have confirmed this with their support while trying to diagnose a IPSEC tunnel remotely. How is that possible? Let’s hope they incorporate this soon…
Refer to my other articles for Cisco & Fortinet’s usage of the command..
Fortinet quietly released 4.0 MR3 Build 0441 yesterday, March 19th. Many fixes not addressed including:
- Infamous FireFox authentication. Bug ID: 128865
- IPS database updates could trigger FortiGate into conserve mode for a few seconds. Bug ID: 139625
- FortiGate may drop connections when AV database update is performed. Bug ID: 123389
The upside, 2 1/2 pages of enhancements – more to come while I digest this release notes…
–Update
Some enhancements -
- Wireless Controller (FINALLY! – One was forced to load a special firmware to support previously)
- Two Factor Authentication
- Enhanced Logging
- Facebook App Control
- FortiASIC traffic offloading
- Much Much More……
So I wanted to test using NexentaStor as an ISCSI target again. NexentaStor v2.5x ISCSI target less than stellar in speed, but I have been told it has greatly improved with COMSTAR. COMSTAR was written from the ground up, one of the last things the OpenSolaris project worked on. I initially created a small 50GB zvol to test a couple virtual machines. The speed appeared to be much improved so I decided to expand it, but when I did on Nexenta, VMware didn’t reflect it. So I tried to refresh the datastore in vsphere client, didn’t see it. I opened up the properties of the ISCSI datastore. There, you’ll notice a button the “increase” Total Capacity – Fig. 1. so I hit increase a viola! It increased it!
VMware needs to extend the volume and does so in seconds. Now I have more space to test with.
Fortinet has recently come out with their version of Access Points. In our next installment, I will explain how to configure this ingenious product from Fortinet. I really enjoy working with this hardware. It allows multiple SSID’s with-in one AP but logically separating them without doing any VLANing on the switch.
If you work with customers who use multiple internet carriers, how do you handle an ISP outage in regards to name resolution? You’ve probably ran into the situation where a LINK reports up, but the actual route is down on the other side of your gateway thus the ISP’s DNS servers are unreachable. Now days, DNS servers published by ISP’s are only reachable with in “their” network. Sure, you can distribute each of the ISP’s DNS as first/second/third, but what happens to the end users browsing experience? It’s slow, not working, down – waiting for that first, second or even third DNS server progression to resolve.
One solution I’ve employed is to use an outside DNS source beyond the ISP such as OpenDNS or Google’s public DNS. To provide redundancy, be sure to push both to PC’s via DHCP.
I’ve seen the subject above in many posts but mine was slightly unique. I could not get my VMware host to mount an NFS volume on another box. My VMware host could see the SAN/NFS host and vice versa. I burned a good 2 hours testing all the basics except for when I examined the “/etc/resolv.conf” on the SAN, which in my case, is Nexenta . Well, like a dummy, I had pointed my DNS to resolve from a VM which, you guessed it, is stored on Nexenta. I updated the “/etc/resolv.conf” with OpenDNS servers and gee whiz, my NFS daemon started working. Talk about a FACEPALM.
Fortinet has the same ability to ping from a particular interface. On a Fortigate, simply enter in the CLI
Assumptions:
Internal: 192.168.42.1
DMZ: 192.168.100.1
WAN1: 10.10.100.254
Customer Side Network: 172.15.30.1
# exec ping-options source 192.168.100.1
(The interface IP you want to source from – in this case the DMZ interface)
# exec ping 172.15.30.1
Pings to 172.15.30.1 on the customer side network will now originate from the DMZ interface.
Typically, when you ping a host, the device will use the closest interface to the destination eg SERIAL 0/1. The problem, however, you need to test an IPSEC tunnel that’s linked to another interface on that device. Let’s assume my LAN interface on my Cisco router is 172.16.1.1. I need to test whether my IPSEC POINT-to-POINT tunnel will generate and pass traffic. Without access to a PC at that location is where extended ping comes in. With extended ping, it’s possible to initiate interesting traffic from a particular interface to cause an event remotely. It’s simple at an enabled prompt example below:
Assumptions:
Each device is already configured with a POINT-to-POINT tunnel.
Access-lists are in place to allow our network (172.16.1.0/24) to access (10.45.4.0/24)
gateway-rtr#
gateway-rtr#ping
Protocol [ip]:
Target IP address: 10.45.4.101
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.16.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.45.4.101, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 32/33/36 ms
gateway-rtr#
Notice the first ping failed. This is due to the time it took to bring up the IPSEC tunnel. As confirmation, you’ll notice where the ping packet was sent from.
