I have a static route on my PIX:

hufcor2# sh static

static (inside,outside) tcp interface https 172.20.1.225 https netmask 255.255.2

55.255 0 0

My Netgear is in on the same network and I believe it is functioning normally. I can access the web interface on the SSL (Netgear) from a browser inside my network. I can also ping the PIX inside address (172.20.1.211) using the Netgear utility. However, when I attempt to ping the outside address - it returns an unreachable message.

In regards to your third question:

When I look at traffic to the local host during an attempt to connection (from the outside) - this is what I receive:

hufcor2# sh local-host 172.20.1.225

Interface inside: 1 active, 1 maximum active, 0 denied

local host: <172.20.1.225>, conn(s)/limit = 1/0

embryonic(s)/limit = 1/0, incomplete(s) = 0

AAA:

Xlate(s):

PAT Global ***.***.***.18(443) Local 172.20.1.225(443)

Conn(s):

TCP out ***.***.***.19:1235 in 172.20.1.225:443 idle 0:00:26 Bytes 0 flags Sa

AB

The ***.***.***.19 address is a wireless router that I have on the public side - where I am connected (& attempting to connect).

If your static PAT and routing is right, then try to "clear xlate" and re-establish the connection (do this after hours). The flag of "show conn" should be UIOB.

1. Check your log , filter by source IP and destination IP ,see if anything wrong

2. create ACL 2-way source IP <-> mapped IP and source IP <-> real ip, then capture the packet and analyze

Thanks,

I have clear xlate several times. From my understanding - when I issue a “show conn”:

hufcor2(config)# sh conn

1 in use, 25 most used

TCP out ***.***.***.19:1139 in 172.20.1.225:443 idle 0:00:02 Bytes 0 flags SaAB

I would understand this to say that my outside connection is reaching my internal SSL at 172.20.1.225.

When I watch the activity to that connection:

hufcor2(config)# sh local-host 172.20.1.225

Interface inside: 1 active, 1 maximum active, 0 denied

local host: <172.20.1.225>, conn(s)/limit = 1/0

embryonic(s)/limit = 1/0, incomplete(s) = 0

AAA:

Xlate(s):

PAT Global ***.***.***.18(443) Local 172.20.1.225(443)

Conn(s):

TCP out ***.***.***.19:1138 in 172.20.1.225:443 idle 0:01:51 Bytes 0 flags Sa

AB

The question I have is with the “TCP out” line. Do I understanding this to mean that it is my SSL (at .225) that is returning the message? Do I need to create a 2-way ACL and how would I accomplish that???

Firewall# show conn foreign 10.10.39.14 detail

10385 in use, 577536 most used

Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,

B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,

E - outside back connection, F - outside FIN, f - inside FIN,

G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data, i -

incomplete,

k - Skinny media, M - SMTP data, m - SIP media, O - outbound data,

P - inside back connection, q - SQL*Net data, R - outside acknowledged FIN,

R - UDP RPC, r - inside acknowledged FIN, S - awaiting inside SYN,

s - awaiting outside SYN, T - SIP, t - SIP transient, U - up

TCP outside:10.10.39.14/1033 inside:192.168.29.37/524 flags UIOB

Notice that the foreign and local host addresses are shown with the firewall interface names where they reside. If you are interested in which host (foreign or local) initiated the connection, you have to interpret the connection flags.

In the preceding example, you can determine the following facts from flags UIOB:

U The connection is up (fully established).

I Inbound data has been received from the foreign host.

O Outbound data has been sent from the local host.

B The initial TCP SYN flag came from the outside (foreign host). Therefore, the connection was initiated by the foreign host.

From your "show conn" output flag "SaAB", it looks 3-way handshake not completed . The firewall received packet from outside ,but don't get syn from SSL server.

Check your server default route, should point to firewall inside interface.

You can use "capture" command to get raw data to analyze what's happening.

access-list cap-outside extended permit ip host ***.***.***.19 host ***.***.***.18

access-list cap-outside extended permit ip host ***.***.***.18 ***.***.***.19

access-list cap-inside extended permit ip host ***.***.***.19 host 172.20.1.225

access-list cap-inside extended permit ip host 172.20.1.225 host ***.***.***.19

then type followed command at CLI

# capture ssl-outside access-list cap-outside interface outside

# capture ssl-inside access-list cap-inside interface inside

then re-establish the session from your outside PC

# show capture ssl-outside

# show capture ssl-inside

Firewall# clear capture ssl-outside

Empties the capture buffer and retains the session

Firewall# no capture ssl-inside

Deletes the capture session and the capture buffer

I am using a PIX 501 with IOS 6.3 (1) installed. Therefore, I do not have the “extended” option available within the ACL command.

What other alternatives do I have???

Also, I am not certain if it is part of the same issue (IOS). However, when I ran a “sh conn foreign” - I did not receive the last line as in your example:

TCP outside:10.10.39.14/1033 inside:192.168.29.37/524 flags UIOB (missing type of line entry is missing from my attempt).

Thanks again,

Conn(s):

TCP out ***.***.***.19:1138 in 172.20.1.225:443 idle 0:01:51 Bytes 0 flags SaAB

this is enough telling you 3-way handshake not completed.

PIX v6.3 not supporting capture data from firewall, you can try analyze log.

#logging on

#logging buffer informational

then start the session from outside

#show log | in *.*.*.19 (your PC from outside)

v6.3 might not support "|" , anyway you can see something happened.