Stealth rule drops inbound connection

[SriniKrish]

Hi Guys,

I am having a specific issue with the Stealth rule dropping an inbound connection.

The internal host is NAT-ed as Hide behind gateway and there is a NAT rule for specific hosts to allow access from internet on specific port.

There is also an internal policy that allows the access on the port

And the access policy is above stealth rule.

Issue:

The initial access is allowed but the connection gets dropped by stealth rule.

Screenshots as attached.

appreciate any directions here !

Thank you

Srini

[Kryten]

The first accept is from your Geo Policy, not from the access rule. It seems that the access rule does not match the traffic and thus gets dropped by the stealth rule.

Not sure about the NAT, I don't see in that NAT rule that it matches only for specific Clients, as the source is set to any. Also I don't think its a good idea to use hide-NAT for outgoing traffic for that host but a static NAT for incoming traffic, but I also don't think that this is the problem here.

[SriniKrish]

Thanks for your comment. Yeah I did realise later that the first hit is geo policy.

The source being Any in the NAT shudnt be a problem as the access policy is for specific host.

To be honest I don't know  why it's not hitting the policy instead the Stealth.

I have  very similar access configured for other servers as you can see in the NAT rule. But some odd reason this one isn't  the case.

[Kryten]

Hard to tell by what I can see in the Screenshots, but my next course of action would be to check if the arriving traffic really matches the IP addresses used in the Objects here. You could try to use fw monitor to see what happens to the incoming traffic, if it gets NATed correctly. Since the access rule does not match, my best guess would be that the destination address is somehow wrong(source does not get NATed it seems, so should be ok),  maybe the NAT does not match for some reason or another NAT rule matches before this one.

You probably have checked these things already, but thats the only reason I can imagine so far why it does not match the access rule.

[SriniKrish]

Hi Kryten,

I did run some captures ( Fw monitor and fw zdebug) as attached. But nothing conclusive.

The drop is at 'i' which is pre-inbound and before firewall vm.

Also have attached a reference NAT rules , there is only one https NAT rule prior to this for the same destination and it works just fine.

pls do let me know if you find anything obvious.

Cheers

Srini

[Kryten]

My best guess at the moment is that the problems are caused by the fact that you use the Gateway Address for this static NAT (and also for Hide NAT). I suggest to use a separate IP address to NAT this statically in both directions and see if it works then.

I don't really have any arguments on why that happens though, but I suspect it might have something to do with the Gateway also using Port 8080 per default when used as a Proxy. Maybe you could(for a test) translate the port as well, so that the client does not use port 8080 from the outside?

[Chris_Atkinson]

Based on the differences in the Allow/Drop log cards have you experimented with the service objects in the rules?

HTTP_proxy   versus  HTTP_and_HTTPS_proxy e.g.

[SriniKrish]

yeah did notice that and tried that already.

[Vishal1]

Hi,

   How did you resolved the issue ? I am facing same issue in my environment.

[Chris_Atkinson]

Is the gateway itself configured as a proxy and with the gateways web portal are you running it on 443 or 4434 ?

[emmap]

The original poster's issue is that the access rule needs to reflect the pre-NAT packet, not the post-NAT. So the destination is wrong.