d4nnyo
asked on
Cisco ASA 5506 - port forwarding not working
We've established port forwarding successfully using the following method below on this firewall. Other services are reachable and working fine.
However, when we moved the service "MYSVC" behind the firewall, the remote company could not access their equipment. Also, our log showed outbound communication attempts from their internal equipment to their network were failing.
Step 1:
object network obj_inside_MYSVC-tcp9000
host 10.0.0.240
object network obj_inside_MYSVC-tcp9001
host 10.0.0.240
Step 2:
object network obj_inside_MYSVC-tcp9000
nat (inside,outside) static interface service tcp 9000 9000
object network obj_inside_MYSVC-tcp9001
nat (inside,outside) static interface service tcp 9001 9001
Step 3:
object-group service obj_svc_MYSVC tcp
port-object eq 9000
port-object eq 9001
Step 4:
object-group protocol MYSVC
protocol-object tcp
Step 5:
access-list outside_access_in extended permit object-group MYSVC any object obj_inside_MYSVC-tcp9000 object-group obj_svc_MYSVC
Is there something incorrect about our method? Is there any reason the above port forwarding config would work for some services, but not others?
However, when we moved the service "MYSVC" behind the firewall, the remote company could not access their equipment. Also, our log showed outbound communication attempts from their internal equipment to their network were failing.
Step 1:
object network obj_inside_MYSVC-tcp9000
host 10.0.0.240
object network obj_inside_MYSVC-tcp9001
host 10.0.0.240
Step 2:
object network obj_inside_MYSVC-tcp9000
nat (inside,outside) static interface service tcp 9000 9000
object network obj_inside_MYSVC-tcp9001
nat (inside,outside) static interface service tcp 9001 9001
Step 3:
object-group service obj_svc_MYSVC tcp
port-object eq 9000
port-object eq 9001
Step 4:
object-group protocol MYSVC
protocol-object tcp
Step 5:
access-list outside_access_in extended permit object-group MYSVC any object obj_inside_MYSVC-tcp9000 object-group obj_svc_MYSVC
Is there something incorrect about our method? Is there any reason the above port forwarding config would work for some services, but not others?
CompProbSolv
Does the service only use TCP? That appears to be how the forwarding is defined.
ASKER
Yes, vendor advised TCP only.
Hi,
host 10.0.0.240 should be allowed to go on the internet, otherwise external requests wouldn't find the way back to source ip address.
So you need first to check that it can go on the on the internet: it should have a nat/pat rule and an access-list on inside interface if an access-group is present.
If this 1st step is confirmed that works, you can easily try if your rule is ok by trying a telnet on those ports from outside: telnet <public_IP_address> 9000.
If you have a response, then your firewall is ok and the problem is elsewhere.
hope this helps
max
host 10.0.0.240 should be allowed to go on the internet, otherwise external requests wouldn't find the way back to source ip address.
So you need first to check that it can go on the on the internet: it should have a nat/pat rule and an access-list on inside interface if an access-group is present.
If this 1st step is confirmed that works, you can easily try if your rule is ok by trying a telnet on those ports from outside: telnet <public_IP_address> 9000.
If you have a response, then your firewall is ok and the problem is elsewhere.
hope this helps
max
I frequently use port forwarding to allow remote access with VNC. It is very easy to change the port number on the VNC server so I will also use it to test if I have port forwarding working correctly. For example, in your case I'd set up a computer with VNC configured for port 9000 and change the IP address in your 5506 to point to the IP address of that computer. I'd test connectivity with the VNC client from another computer on the same network to confirm that I have the computer configured correctly. Then I'd test from a computer outside of the network to confirm that I have port forwarding configured correctly. Lastly, I'd change the port (in VNC and in the 5506) to 9001 and test again.
If all work, you've confirmed that your port forwarding is working correctly for TCP ports 9000 and 9001. If it doesn't work for MYSVC to 10.0.0.240 as originally configured, then the issue is not with port forwarding but with the computer at 10.0.0.240 or with the specs on what needs to be forwarded.
If all work, you've confirmed that your port forwarding is working correctly for TCP ports 9000 and 9001. If it doesn't work for MYSVC to 10.0.0.240 as originally configured, then the issue is not with port forwarding but with the computer at 10.0.0.240 or with the specs on what needs to be forwarded.
@max:
I like your telnet suggestion but haven't tried it so universally.
Is it safe to assume that any device that has a TCP service will respond to a telnet connection? I've used this before with email servers (and telnet servers, of course) but never considered that I could use it with anything that has a TCP service.
I like your telnet suggestion but haven't tried it so universally.
Is it safe to assume that any device that has a TCP service will respond to a telnet connection? I've used this before with email servers (and telnet servers, of course) but never considered that I could use it with anything that has a TCP service.
It does respond. 100%. It might respond with a blank window should the application under that service give no answer for security reason.
max
max
ASKER
Hi Max,
Sorry, forgot to mention that when vendor's host was at 10.0.0.240, we could successfully telnet to 10.0.0.240 on 9000 and 9001.
Is that the absolute limit of our responsibility?
Sorry, forgot to mention that when vendor's host was at 10.0.0.240, we could successfully telnet to 10.0.0.240 on 9000 and 9001.
Is that the absolute limit of our responsibility?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Max, yes, I worded it incorrectly. Using a public admin website, we can telnet successfully to the public IP on those ports.
Vendor pushed back but we advised them there was nothing else we could do. I appreciate the confirmation.
Vendor pushed back but we advised them there was nothing else we could do. I appreciate the confirmation.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.