I work for a Fortinet partner, and in the last few months I've been doing more and more work with their Fortigate line. Tonight I just discovered a really handy "feature" that has allowed me to test a change that $Provider made to their routing that I wasn't able to test directly. Details after the jump.
The scenario is I have a shiny new IPsec VPN from my Fortigate to a third party device (I think it's a Sonicwall... Not important). The subnet at that location is 192.168.101.0/24. I have a server farm at my site, in the subnet of 10.10.10.30/24. My Fortigate DOES NOT have a 10.10.10.0/24 address as their is an air gap network separating the Fortigate from the server farm. The router that sits on that other boundary is managed by $Provider, and I have to request new subnets be routed to me every time I add a new site-to-site VPN.
Yes, that's stupid, but that's not the point here ;)
So, as with IPsec VPNs I have to define the source and destination networks to route over the VPN. In Cisco speak this is configuring the Crypto ACL or interesting traffic. In this case I only have a source of 10.10.10.0/24 and a destination of 192.168.101.0/24.
How can I test this when the only access I have it to the Fortigate? By spoofing!
Please allow me to demonstrate.
On the Fortigate CLI you first specify the source using the 'execute ping-options source' command. The kicker here is that the Fortigate doesn't check at all to see if the IP you specify is actually configured on any of its interfaces, it just accepts the command. Next you then run your ping using the 'execute ping x.x.x.x' command.
That's all there is to it!
Here's a screenshot showing me doing this exact test. The window on the left shows me setting the source, and running the ping and the window on the right shows me running a packet sniffer on the Fortigate capturing ICMP. You'll see both the echo request AND the echo replies!
Notice that the ping fails on the left window. That's because I don't have 192.168.101.1 as a configured address. The replies are actually being sent down the VPN towards the new site. If there is a real 192.168.101.1 it's now receiving a whole bunch of echo replies that it never sent requests for!
Anyway, just thought I'd share. Enjoy!
Neat! I've used the Packet Tracer function in the ASA to kick up tunnels before with a spoofed packet as well. When yo use that function in the ASA it generates the packet in memory and passes it all the way through the ASA's policy functions until it's ready to queue it for transmission. I've found that this will trigger phase 1 and 2 of a VPN to come up so I've used it in cases where the VPN definition is such that I can't easily generate a real packet from the device I'm working on.
ReplyDeleteI wish you could do this for execute traceroute :(
ReplyDeleteI'm not sure how that would be useful. You'd never get the response so every traceroute would look the exact same: no hops at all.
Delete