Odd traffic issues

[#1]

I' ve got a location that I have setup with their own VDOM. They have their systems and servers and then some public access areas. In order to restrict access to their systems they put a PIX device in put all the servers behind the pix. There are no internal issues. The problem they are having is the following: servers behind the pix when going out the the Internet through the Fortigate have intermittent success. Traceroutes will complete eventually but only 1 to 4 of the hops resolve, the rest appear to be timeouts. The hops that do resolve are not always the same. I' ve got routes for their server network as well as other networks on the Fortigate and I have no issues reaching the servers from the Fortigate. Is anyone aware of any Hide NAT issues when putting another firewall device behind a Fortigate?

[UkWizard]

I do not know of any issues. I am presuming pings also fail? Does the PIX do any nat at all? Sounds like a possible issue between the two firewalls, like link speed/duplex mismatch. If you get dropped pings to the web, try pings to the inside of the fortinet and then the outside of the pix? If you see dropped pings at the fortinet but not the pix, then there is a network issue between these two points. Only other thing i can think off, is MTU issues perhaps, when travelling through two firewalls. I presume also that you only have one network connection, yes? If none of the above helps, you will need to provide more info really.

[#3]

I' m putting a device on their public network right now. I' m also checking the network settings at each device across the network. From what I just found however the problem is a little more complicated than reported. I' ll post an update later.

[romanr]

When using 2 inline Firewall you should use the " norandomseq" parameter in the " static" rules on the pix.... Have you tried this? I encountered some similar issues some time ago.... But using the fixed it.... " static (inside,outside) XXX YYYY netmask 255.255.255.255 0 0 norandomseq" cheers.roman

[#5]

It seems any device on that VLAN is unable to traceroute cleanly. Here' s what a traceroute from that network looks like: The first 3 hops are default gateway, internal fortigate interface, external address for network 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 29 ms 41 ms 24 ms py-in-f147.google.com [64.233.167.147] Pings work fine and you can browse the web.

[UkWizard]

Their was no previous mention of VLANS, so you are going to need to illustrate your setup i think. I have seen firewalls dropping traceroute traffic, so that can be a red herring. Whats the actual problems that you see. If a constant ping isnt dropping, the traceroute results may need to be ignored.

[rwpatterson]

Sometimes there are devices in the middle that do not allow DNS resolution. As long as you can get end to end, I wouldn' t sweat the small stuff.

[#8]

I understand that it may not be an issue or I may be chasing the wrong issue however another VDOM that passes through the same equipment doesn' t have this issue. All the hops resolve. It' s not a show-stopper just finding it odd that only one VDOM is having this issue. I' m opened this with TAC so I' ll see if they can find something. It' s probably something simple that I' m overlooking because I' m too close, kinda like that colon instead of a semicolon to end a statement when programming. Thanks for the suggestions. If we find anything fun or really odd I' ll update the thread.