Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
SriniKrish
Collaborator

Stealth rule drops inbound connection

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

0 Kudos
10 Replies
Kryten
Collaborator

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
Collaborator

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.

0 Kudos
Kryten
Collaborator

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.

0 Kudos
SriniKrish
Collaborator

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

 

0 Kudos
Kryten
Collaborator

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?

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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.

 

proxy.png

CCSM R77/R80/ELITE
0 Kudos
SriniKrish
Collaborator

yeah did notice that and tried that already.

0 Kudos
Vishal1
Explorer

Hi,

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

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
emmap
Employee
Employee

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events