01-22-2008 02:23 PM - edited 03-11-2019 04:52 AM
Hello,
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 0.0.0.0 0.0.0.0 ***.***.***.17 1 OTHER static
outside ***.***.***.16 255.255.255.248 ***.***.***.18 1 CONNECT static
inside 172.20.0.0 255.255.0.0 172.20.1.211 1 CONNECT static
I cannot see what is causing my issue? Please adviseâ¦
01-22-2008 02:29 PM
Hi
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 172.20.0.0 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
HTH
Jon
01-22-2008 03:44 PM
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).
01-22-2008 09:13 PM
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
01-23-2008 12:12 PM
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???
01-23-2008 08:17 PM
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
01-24-2008 03:01 PM
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,
01-24-2008 07:04 PM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: