incomplete action

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

incomplete action

Not applicable

hello

we have our own web server which we host web sites from

I have setup my incoming nat rule follow

source zone = untrusted

des zone = umtrusted

des address = my internet port ip

service = service-http

des tran = my local web server ip

Security rule

source zone = untrusted

des zone = trusted

des address = my local web server ip

app = web-browsing

in the traffice log, i see traffice coming in but coming up as incomplete, it knows its port 80, its destination is my internet port ip on the pan?

what have i missed?

Mark

5 REPLIES 5

L4 Transporter

Hi Mark,

Incomplete means that either the three way tcp handshake did NOT complete or the three way tcp handshake did complete but there was no data after the handshake to identify the application. In other words that traffic you are seeing is not really an application.
So to explain a little clearer, if a client sends a server a syn and the paloalto device creates a session for that syn, but the server never sends a syn ack in response back to the client, then that session would be seen as incomplete.

Also, this may caused due to incorrect Rule setup.

Your NAT rule appears to be fine, the only change you need to make is in your security rule:-

Destination Address: Public Ip-address

After this change you should be able to get it working. Let me know if that helps.

Regards,

Parth

So it still not working

Here are mySecurity Rule

cid:image001.png@01CD4870.43A92CF0

Here are my NAT Rules

cid:image002.png@01CD4870.43A92CF0

Regards,

Mark

Your configuration appears to be correct. The next steps would be to verify we are applying the NAT to the traffic and sending it to the server correctly.

This can be done via CLI

> show session all filter source <src ip address in testing>

> show session id <id number>

Here is an example output where 172.18.33.34 is my external testing client with 172.18.3.10 as my public IP and 172.24.53.55 as the internal address. Verify the correct s2c flow source address, rule, nat-rule, and ingress/egress interfaces.

> show session all filter source 172.18.33.34

31313   web-browsing   ACTIVE  FLOW  ND   172.18.33.34[59092]/Untrust/6  (172.18.33.34[59092])

vsys1                                     172.18.3.10[80]/DMZ  (172.24.53.55[80])

> show session id 31313


Session           31313
        c2s flow:              

source:      172.18.33.34 [Untrust]              

dst:         172.18.3.10              

proto:       6

sport:       59092          dport:      80              

state:       INIT           

type:       FLOW              

        s2c flow:              

source:      172.24.53.55 [DMZ]           <--------- Internal Address    

dst:         172.18.33.34              

proto:       6              

sport:       80              dport:      59092              

state:       INIT           

type:       FLOW

start time                    : Tue Jun 12 11:47:07 2012      

total byte count(c2s)         : 763      

total byte count(s2c)         : 530      

layer7 packet count(c2s)      : 6      

layer7 packet count(s2c)      : 5      

application                   : web-browsing      

rule                          : web server        <------------ Security Rule 

address/port translation      : source + destination      

nat-rule                      : inbound web(vsys1)       

ingress interface             : ethernet1/3      

egress interface              : ethernet1/2.53

If the output looks correct then the following could be the case:

- web server not receiving SYN (problem with PAN sending SYN out or device in between)

- web server receiving SYN and not responding(problem with web server service/route/firewall)

- web server receiving SYN and responding with SYN-ACK(need to check with pcaps if PAN is receiving SYN-ACK)

To find which case is true you can enable pcaps on the PAN or on the web server itself.

See attached,   its hitting the rule i think.

The session does look correct. Also we can see there are no s2c packets:

layer7 packet count(s2c)      : 0

I would refer to my previous post as it appears the PAN is not receiving SYN-ACK from the server

- web server not receiving SYN (problem with PAN sending SYN out or device in between)

- web server receiving SYN and not responding(problem with web server service/route/firewall)

- web server receiving SYN and responding with SYN-ACK(need to check with pcaps if PAN is receiving SYN-ACK)

- Stefan

  • 5677 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!