07-09-2013 03:54 AM - edited 03-11-2019 07:09 PM
Hi,
I added line 2 with line 1 already existing to our firewall and tested with "C:\>telnet outside_int_IP 2021 did thesame for inside_int_IP 2021 but got a message "....could not open connection to the host on port 2021 in each case. Do you know what might be the reason for that?
static (Inside,Outside) tcp outside_int_IP 2020 inside_int_IP 2020 netmask 255.255.255.255 - This is existing
static (Inside,Outside) tcp outside_int_IP 2021 inside_int_IP 2021 netmask 255.255.255.255 - Just added this
access-list Outside_access_in extended permit tcp any host outside_int_IP eq 2021
Solved! Go to Solution.
07-09-2013 08:28 AM
Hi,
It would seem to go through just fine.
So I would have to guess the problem might be on the host behind the firewall.
You could test the connection through the ASA from the Internet and at the same time monitor logs through ASDM in real time and find the "Built" and "Teardown" messages for the TCP connection and see what the Teardown reason is.
I would presume that it might be SYN Timeout which would point to a situation where the host doesnt reply.
- Jouni
07-09-2013 03:59 AM
Hi,
Can you take the "packet-tracer" output of those tests?
For example
packet-tracer input Outside tcp 1.1.1.1 12345
packet-tracer input Outside tcp 1.1.1.1 12345
If this doesnt tell us the problem then we might need to see some other configurations.
Is the ACL "Outside_access_in" attached to the "Outside" interface with the command "access-group Outside_access_in in interface Outside" ?
- Jouni
07-09-2013 04:08 AM
yes there is access-group that is attached to the outside.
"access-group Outside_access_in in interface Outside"
static (Inside,Outside) tcp outside_int_IP 2020 inside_int_IP 2020 netmask 255.255.255.255 - This is existing and it works when i telnet to the port and the second (the new one) doesn't.
Do you see anything wrong with the above config?
07-09-2013 04:25 AM
Hi,
I cant see any problem with the configuration.
Can you provide us with the "packet-tracer" output to further troubleshoot this problem
- Jouni
07-09-2013 05:45 AM
See the output of packet tracer below
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in x.x.x.x 255.255.0.0 Inside
Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 Outside
Phase: 4
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: Outside
input-status: up
input-line-status: up
output-interface: Inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
07-09-2013 05:51 AM
Hi,
Are you sure you used the public IP address as the destination of the "packet-tracer" test?
If yes, then can you share the configurations?
- Jouni
07-09-2013 06:06 AM
Public IP is the source while internal is my destination of the packet-tracer command. should public be the destination?
07-09-2013 06:55 AM
Hi,
Yes, the public NAT IP address should be the destination IP address of the "packet-tracer" command.
We are attempting to simulate a connection coming from the Internet to a server on your LAN. Naturally when the packet is just entering your ASA it will be destined to the public IP address rather than the local IP address that is not even routable on the Internet.
If the connection on the other port works and the other one doesnt there is naturally always the chance that some software firewall is preventing the connection or the host is simply not listening on that port for a connection to even form.
- Jouni
07-09-2013 07:10 AM
Thanks for your response. In this case what would be my source IP can i use a generic IP as source?
btw - I see a hit on "access-list Outside_access_in extended permit tcp any host outside_int_IP eq 2021", When i did a show "access-list". The hit increments each time i do a telnet on that port.
07-09-2013 07:19 AM
Hi,
You can use anything as a source that the ASA doesnt have a specific route for through another interface.
For example I typically use 1.1.1.1 or something similiar.
I think your NAT and ACL are probably correct but the "packet-tracer" would confirm that usually.
It might be as I said that the problem is on the actual host that is hosting the service on that port.
- Jouni
07-09-2013 07:59 AM
Hi Jouni,
Thanks for responding.... see below result of packet tracer.
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (Inside,Outside) tcp 65.x.x.x 2021 10.x.x.x 2021 netmask 255.255.255.255
match tcp Inside host 10.x.x.x eq 2021 Outside any
static translation to 65.x.x.x/2021
translate_hits = 0, untranslate_hits = 48
Additional Information:
NAT divert to egress interface Inside
Untranslate 65.x.x.x/2021 to 10.x.x.x/2021 using netmask 255.255.255.255
Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 Outside
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group Outside_access_in in interface Outside
access-list Outside_access_in extended permit tcp any host 65.x.x.x object-group DM_INLINE_TCP_13
object-group service DM_INLINE_TCP_13 tcp
port-object eq 2020
port-object eq 2021
Additional Information:
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: IDS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 9
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (Inside,Outside) tcp 65.x.x.x/2021 10.x.x.x/2021 netmask 255.255.255.255
match tcp Inside host 10.x.x.x eq 2021 Outside any
static translation to 65.x.x.x/2021
translate_hits = 0, untranslate_hits = 48
Additional Information:
Phase: 10
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (Inside,Outside) tcp 65.x.x.x/2020 10.x.x.x/2021 netmask 255.255.255.255
match tcp Inside host 10.x.x.x eq 9970 Outside any
static translation to 65.x.x.x/2021
translate_hits = 0, untranslate_hits = 7
Additional Information:
Phase: 11
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 12
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 258578431, packet dispatched to next module
Result:
input-interface: Outside
input-status: up
input-line-status: up
output-interface: Inside
output-status: up
output-line-status: up
Action: allow
07-09-2013 08:28 AM
Hi,
It would seem to go through just fine.
So I would have to guess the problem might be on the host behind the firewall.
You could test the connection through the ASA from the Internet and at the same time monitor logs through ASDM in real time and find the "Built" and "Teardown" messages for the TCP connection and see what the Teardown reason is.
I would presume that it might be SYN Timeout which would point to a situation where the host doesnt reply.
- Jouni
07-09-2013 08:51 AM
Thanks Juoni.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide