Trouble with SSL Connection via PIX

Unanswered Question
Jan 22nd, 2008
User Badges:


I am having issues attempting to connect to a Netgear SSL Concentrator within my internal network. The connection from the outside of my network is being routed through my PIX 501 in order to reach my SSL.

When I attempt to make the connection from a web browser - it simply returns an error message stating that it timed out.

This is my ACL:

hufcor2# sh access-list

access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 256)

alert-interval 300

access-list 101; 1 elements

access-list 101 line 1 permit tcp any interface outside eq https (hitcnt=183)

My Routes:

hufcor2# sh route

outside ***.***.***.17 1 OTHER static

outside ***.***.***.16 ***.***.***.18 1 CONNECT static

inside 1 CONNECT static

I cannot see what is causing my issue? Please advise…

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jon Marshall Tue, 01/22/2008 - 14:29
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN


Couple of things to check

1) You have a static translation on the pix ie.

static (inside,outside) tcp interface 443 "Netgear IP" 443

2) Is the Netgear on the network -if not do you have routes on the pix for the netgear subnet

3) Does the netgear device know how to route the return packets back to the pix ie. what is the source IP address when you try and connect and does the netgear route this address back to your pix



hufcor Tue, 01/22/2008 - 15:44
User Badges:

I have a static route on my PIX:

hufcor2# sh static

static (inside,outside) tcp interface https 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 ( 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

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

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

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



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


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


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

pengfang Tue, 01/22/2008 - 21:13
User Badges:

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

hufcor Wed, 01/23/2008 - 12:12
User Badges:


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 idle 0:00:02 Bytes 0 flags SaAB

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

When I watch the activity to that connection:

hufcor2(config)# sh local-host

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

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

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



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


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


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???

pengfang Wed, 01/23/2008 - 20:17
User Badges:

Firewall# show conn foreign 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 -


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: inside: 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

access-list cap-inside extended permit ip host 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

hufcor Thu, 01/24/2008 - 15:01
User Badges:

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: inside: flags UIOB (missing type of line entry is missing from my attempt).

Thanks again,

pengfang Thu, 01/24/2008 - 19:04
User Badges:


TCP out ***.***.***.19:1138 in 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.


This Discussion