Announcement

Collapse
No announcement yet.

VPNdial up and port forwarding to 8080

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • ronmerr
    started a topic VPNdial up and port forwarding to 8080

    VPNdial up and port forwarding to 8080

    I'm in need of some insight into how to configure a port forwarding rule on my ASA for my dial up VPN users. First some background.

    The server in question sits in our DMZ on an ip of 10.10.100.149. it has a webservice that listens on port 8080. What I have done todate is allow external users (from the world) connect to this server on port 8080 from a port 80 request by entering a static rule on my ASA as such:

    static (dmz,outside) tcp {public server name} www {private server name} 8080 netmask 255.255.255.255

    I have also set a static rule that allows our office staff to connect to this server in the dmz via the same method as such:

    static (dmz,office) tcp {private server name} www
    {private server name} 8080 netmask 255.255.255.255

    the purpose of mentioning this is to show that the server is accessible. So here is my issue:

    I have VPN dial in using the Cisco VPN client 5.0.01.0600 with the following settings:

    Client Side
    Allow transparent tunneling
    Connect as IPSEC over UDP (NAT/PAT)
    Allow Local LAN access

    cisco ASA config
    Split Tunneling in my CISCO .cfg for all our subnets.

    The clients pull an Address from the VPN pool of 10.10.124.129/255.255.255.128

    These clients cannot connect to the web-application unless they enter the URL with the :8080 prefix.

    My problem is I don't fully understand how the Cisco ASA handles the VPN connection and how I can tell the ASA that if a connection comes in on the VPN tunnel to have a rule that will port forward the port 80 request to the 8080 port.

    I can't be the only one that has had this issue, so any insight would be of service to me.

    Thanks.


  • ryansmitty
    replied
    Re: VPNdial up and port forwarding to 8080

    Hey


    Long time no chat! This makes this an even more interesting problem to solve. Im not sure to the extent the TAC engineer helped you troubleshoot, but do you still have the second nat entry that i suggest configured on your device? If so and when you attempt connection from a vpn client to the dmz server for PAT do you see any translation hits for that particulart entry when using the sh xlate command?

    The other thing I am wondering is when you created your remote access vpn, did you use asdm or configure it by hand? There is an option to bypass the ACL on the outside interface which is turned on by default. Did you by chance disable that feature?

    The utlimate way to really see what is going on is obviously by getting a packet capture sample when the vpn user tries to connect to the dmz host. Again assuming that you may have used ASDM you could use the packet tracer utility to simulate what happens when a vpn user tries to connect to the dmz host.

    I know this is probably a long winded reply but I just want to try to cover as many bases as possible. Not to mention I would like to see if we can beat the TAC engineer with a solution before they respond !

    Leave a comment:


  • ronmerr
    replied
    Re: VPNdial up and port forwarding to 8080

    Ryan,

    Sorry to take so long to get back on this post. I had to put this issue on the back burner for a while. I'm going to look at that link you had in your post and will get back to you with some feedback. As for sharing my packet captures; I have no issue with that. I should have some detail in the near future. As an aside I also opened a TAC case at Cisco and I even have the engineer there stumped. Yeah!,,,not...

    Leave a comment:


  • ryansmitty
    replied
    Re: VPNdial up and port forwarding to 8080

    ronmerr

    While collecting logs try configuring the ASA to do a packet capture.

    http://analysisandreview.com/cisco/h...the-cisco-asa/

    Once you get it set up, do a test connection and then extract the capture file and open it in wireshark or some other packet analyzer. If possible could you post your scrubbed logs to share with me?

    Leave a comment:


  • ronmerr
    replied
    Re: VPNdial up and port forwarding to 8080

    Ryan,

    You were correct in that I do not get the "duplicate static" error, but that particular configuration did not work. I'm getting some logs from the ASA to see what is happening to packets coming in on the VPN and we'll see what I can find out.

    Leave a comment:


  • ryansmitty
    replied
    Re: VPNdial up and port forwarding to 8080

    Try the following

    static (outside,dmz) tcp <private> 80 <private> 8080 netmask 255.255.255.255

    My thinking is that your VPN traffic is leaving your outside interface however it is using private addresses distributed via your DHCP pool. Because of that we want the traffic destined to your dmz server not have to nat but still perform the port translation when your vpn traffic tries to connect that specific server (at least during the VPN session).

    Let me know if that works or not. If I understand this correctly then you should not get a message "duplicate static" error.

    Ryan
    Last edited by ryansmitty; 25th August 2009, 20:52.

    Leave a comment:


  • ronmerr
    replied
    Re: VPNdial up and port forwarding to 8080

    Ryan,

    Here is what I feel to be relevant data from my .cfg file. Keep in mind that VPN users are able to access servers in the DMZ on port 80. It's this 8080 thing on this one server that is gumming up the works.

    Ryan,

    Without dumping my whole .cfg file on you, here are the bits that I feel are relevant to the server in question and the VPN hosts. If you need more detail, let me know.

    Names
    name 10.10.100.149 private_server_name
    name aaa.bbb.ccc.ddd public_server_name

    Access Lists

    From outside interface to dmz
    access-list from-outside-coming-in extended permit tcp any host public_server_name eq www
    access-list from-outside-coming-in extended permit ip 10.10.124.128 255.255.255.128 any
    comment: VPN network

    dmz nat ACL for outbound NAT’d traffic
    access-list dmz_nat_outbound extended permit ip 10.10.96.0 255.255.224.0 10.10.124.128 255.255.255.128
    comment: Yup the .96 network is huge, don’t ask

    nonat ACL for VPN traffic
    access-list nonat extended permit ip any 10.10.124.128 255.255.255.128

    IP local pool for VPN address assignment
    ip local pool cisco_ipsec_pool 10.10.124.129-10.10.124.254 mask 255.255.255.128

    NAT
    global (outside) 1 interface
    nat (inside) 0 access-list nonat
    nat (inside) 1 0.0.0.0 0.0.0.0
    nat (office) 0 access-list nonat
    nat (office) 1 0.0.0.0 0.0.0.0
    nat (guest) 1 0.0.0.0 0.0.0.0
    nat (dmz) 0 access-list dmz_nat_outbound
    nat (dmz) 1 0.0.0.0 0.0.0.0
    nat (circuits) 0 access-list nonat
    nat (circuits) 1 0.0.0.0 0.0.0.0


    Static Mappings
    static (dmz,outside) tcp public_server_name www private_server_name 8080 netmask 255.255.255.255
    static (dmz,office) tcp private_server_name www private_server_name 8080 netmask 255.255.255.255

    Access Groups
    access-group from-outside-coming-in in interface outside
    access-group from-insidezone-coming-in in interface inside
    access-group office_access_in in interface office
    access-group guest_access_in in interface guest
    access-group from-dmz-coming-in in interface dmz
    access-group circuits_access_in in interface circuits



    Leave a comment:


  • ronmerr
    replied
    Re: VPNdial up and port forwarding to 8080

    Let me put some stuff together and I'll reply again to this post

    Leave a comment:


  • ryansmitty
    replied
    Re: VPNdial up and port forwarding to 8080

    Is your 10.10.124.128/26 subnet on a different interface? Your outside interface terminates your tunnel, however the dhcp pool is a different subnet than your office interface (remembering from the last post). If you could supply just a little more info on your ASA and we should be able to knock this issue out.

    Ryan

    Leave a comment:

Working...
X