- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No internet access for odd IP addresses
That might sound like I need to verify IP addresses, but that is not the case. I have an interesting problem that I need to address and was wondering if anyone had any insight or experience with this issue. We recently purchased a 100e to replace an old, and dying, ASA5510. The initial setup went smoothly and all traffic was flowing as expected.
I had to add a second, separate but similar, network for SFTP traffic. The IP scheme was close but not an exact match. This part also went smoothly.
I have recently been tasked with configuring a test network for training purposes. I went about the same process as I did adding in the second network, but ran into a small issue. Even numbered IP addresses can hit the internet, but odd numbered IP addresses are stopped at the firewall. For simplicity sake, I opened the ports up to all traffic but still get blocked when using an IP address that has a final octet that ends in an odd number. For example, X.X.X.132 will work, but X.X.X.45 will not work. All IP addresses can ping the firewall and internal communication is fine.
Any thoughts or insight would be appreciated.
Solved! Go to Solution.
- Labels:
-
5.4
Nominate a Forum Post for Knowledge Article Creation
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
just run an "debug flow" to show us the processing of your traffic:
http://kb.fortinet.com/kb/documentLink.do?externalID=FD33882
Please collect an debug flow of an even and one debug flow of an odd ip-address.
Regards
bommi
NSE 4/5/7
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That sounds like you have WAN LLB configured.
You can additionally to "debug flow" use the internal sniffer to see where the traffic stops:
diag deb en
diag sniffer packet any 'icmp and host a.b.c.11' 4 0 a
You would expect to see the packet on 'internal' and then on 'wan1'. Repeat with an even-numbered host.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
just run an "debug flow" to show us the processing of your traffic:
http://kb.fortinet.com/kb/documentLink.do?externalID=FD33882
Please collect an debug flow of an even and one debug flow of an odd ip-address.
Regards
bommi
NSE 4/5/7
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That sounds like you have WAN LLB configured.
You can additionally to "debug flow" use the internal sniffer to see where the traffic stops:
diag deb en
diag sniffer packet any 'icmp and host a.b.c.11' 4 0 a
You would expect to see the packet on 'internal' and then on 'wan1'. Repeat with an even-numbered host.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you both for the recommendations! For some reason all odd numbered IPs were attempting to route through my secondary WAN interface rather than the primary. Turning that off instantly corrected the problem, just not necessarily with the desired configuration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maybe some left-over from trying out LLB?
On the CLI, type "show full" and save the output into a file. Search for "WAN2" or "LLB" or the like.
LLB distributes sessions by looking at the source IP (one of the available choices). With only 2 WAN ports, you get the split into even and odd addresses.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did find some WAN2 information, but everything looked correct. It looks like I've been chasing my tail though as troubleshooting what I thought was a completely unrelated issue ended up correcting my problem. I had to run "diagnose firewall iprope flush", which cleared the other issue that I was having (couldn't ping between DMZ and LAN). Once I resolved that issue I went back, re-enabled the policies that I had disabled, re-ran the flush and had the access that I was expecting.
I did find it interesting that a problem that was apparently around in 2014 would still be an issue in a newer release. I'll just write this off as a learning experience and move on.
Thanks for the help!