Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Advntrhike
New Contributor

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.

2 Solutions
bommi
Contributor III

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

View solution in original post

NSE 4/5/7
ede_pfau

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
5 REPLIES 5
bommi
Contributor III

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

NSE 4/5/7
ede_pfau

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Advntrhike

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.

ede_pfau

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Advntrhike

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!

Labels
Top Kudoed Authors