Wireless Access

last person joined: an hour ago 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

Port Forwarding Issue

  • 1.  Port Forwarding Issue

    Posted Apr 27, 2019 05:28 PM

    I have my Aruba 7005 controller running 8.4.x set up as router connected directly to my cable modem.  I have port forwarding enabled after following a few other posts (1, 2, 3).  Everything works well except one issue.  Devices with internal IPs aren't being port forwarded when trying to communicate with the public port-forwarded host/IP.  External traffic work wells and does get port-forwarded OK.

     

    To explain futher, I have set up a public hostname for my public IP, grimace.dyndns.biz.  I have a local service running on my network (192.168.1.51 with port 9443) that I want to serve to the internet. Traffic from the internet can successfully communicate with grimace.dyndns.biz:9443.  But other devices internal to the network cannot.  i.e. My laptop with 192.168.1.22 can't communicate with grimace.dyndns.biz:9443.

     

    Here's my relevant config:

     

    ip dhcp pool local
    default-router 192.168.1.1
    dns-server import
    domain-name grimace.dyndns.biz
    network 192.168.1.0 255.255.255.0
    
    interface vlan 1
    ip address 192.168.1.1 255.255.255.0
    ip nat inside
    
    # VLAN connected to my cable modem
    interface vlan 100
    ip address dhcp-client
    ip nat outside
    
    ip access-list session controller-uplink-acl
    any any svc-dhcp permit
    any any tcp 9443 dst-nat ip 192.168.1.51 9443 log
    any any any deny log
    
    interface gigabitethernet 0/0/0
    ip access-group session "controller-uplink-acl"
    switchport access vlan 100
    
    firewall cp
    ipv6 deny any proto 0 ports 0 65535
    ipv4 permit any proto 6 ports 9443 9443

     

    I ran a packet capture on the 192.168.1.51 server and got no hits when making the internal request.  On the controller session datapath, it just shows a `YC` error.  In these logs, note that grimace.dyndns.biz resolves to 24.4.39.46 (not in real world but obfuscated for privacy).

     

    show datapath session table | include 9443
    192.168.1.22 24.4.39.46 6 61501 9443 1/0 0 24 0 0/0/1 3 1 64 YC 6
    24.4.39.46 192.168.1.22 6 9443 61501 0/0 0 24 0 0/0/1 3 1 40 F

    What am I missing?  Some sort of additional routing config?  IP natting issue?



  • 2.  RE: Port Forwarding Issue

    Posted Apr 27, 2019 08:35 PM

    The Y flag means it is not TCP, but it can be observed for a UDP transaction.

     

    You should type "show acl hits" to see if that port ACL is being hit, and how many times.

     

    Besides that, your work looks correct.



  • 3.  RE: Port Forwarding Issue

    Posted Apr 27, 2019 10:14 PM

    The traffic should be TCP.  I'm doing HTTPS requests.  Also, no ACL hits when attempting the request from inside the 192.168.1.x network.

     

    (Aruba7005_B8_C5_88) [mynode] #clear acl hits
    (Aruba7005_B8_C5_88) [mynode] #show acl hits
    
    User Role ACL Hits
    ------------------
    Role  Policy  Src  Dst  Service/Application  Action  Dest/Opcode  New Hits  Total Hits  Index  Ipv4/Ipv6
    ----  ------  ---  ---  -------------------  ------  -----------  --------  ----------  -----  ---------
    
    Port Based Session/Route ACL
    ----------------------------
    Policy  Src  Dst  Service/Application  Action  Dest/Opcode  New Hits  Total Hits  Index  Ipv4/Ipv6
    ------  ---  ---  -------------------  ------  -----------  --------  ----------  -----  ---------
    
    Port ACL Hits
    -------------
    ACL  ACE  New Hits  Total Hits  Index  Ipv4/Ipv6
    ---  ---  --------  ----------  -----  ---------

    My best guess is the internal traffic detects I'm trying to go outbound, sees that the 0/0/0 port IP has the same outbound IP as the destination so it doesn't route outwards, and then never it hits the port-forwarding ACL.  Is this possible?  Any workaround?



  • 4.  RE: Port Forwarding Issue

    Posted Apr 28, 2019 09:22 AM

    Try removing ip nat outside from your external (100) vlan.  Only ip nat inside (on internal vlans) or ip nat outside on vlan 100 are necessary.  I have not personally configured both.  Also, it is worrying that you have not seen any ACL hits.

     

    Last EDIT:

     

    I would also be specific with your ACL like:

     

    any host <public ip address> tcp 9443 dst-nat ip 192.168.1.51 9443 log


  • 5.  RE: Port Forwarding Issue

    Posted Apr 29, 2019 01:36 PM

    Thanks @cjoseph for the response.  I tried removing `ip nat outside` on vlan 100 but keeping `ip nat inside` on vlan 1.  I also tried the reverse.  Both didn't hurt in that external traffic still works and internal clients can still reach internet.  But the changes also didn't improve things since internal traffic still doesn't get natted.  I also tried making the ACL specific with the external IP as destination but it didn't hurt/improve things either.

     

    The only solution I found was to replicate the port-forwarding ACLs to the internal ports.  This would seem to confirm my previous hunch about it being a routing issue where the traffic never hits the uplink ACL.  Workaround:

     

    ip access-list session internal-acl
    any host 24.4.39.46 tcp 9443 dst-nat ip 192.168.1.51 9443
    any any any permit
    !
    
    interface range gigabitethernet 0/0/1-0/3
    ip access-group session internal-acl 
    !

    This workaround isn't ideal since I have a dynamic IP from my ISP so I'd have to update these ACLs every time my IP changes.  I thought I could get around this by using a netdestination/alias with my dynamic DNS hostname but interestingly, this doesn't work for internal or external traffic (neither gets port forwarded).  The controller lists the DNS name in `show firewall dns-names` but for some reason, it always has an empty "List"/resolve value.

     

    I'm still interested in a better/cleaner solution if @cjoseph or anyone else has one.



  • 6.  RE: Port Forwarding Issue

    Posted Apr 29, 2019 02:37 PM
    This is always an issue with firewall. The public IP address is bind to the external interface. With many firewalls we must do some tricks to make this public IP available at the LAN interfaces.

    I think your ACL is the solution for this.
    You can work with an alias to make it flexible, but I don't now of this will work in your case.
    Example

    netdestination wan-ip
    host vlan 4094 offset 1
    !

    The offset is the host address in the subnet for example the first host address.

    To verify

    show netdestination wan-ip verbose

    This alias can be used in you ACL.


  • 7.  RE: Port Forwarding Issue

    Posted Apr 30, 2019 01:09 PM

    Thanks @

     

     

    #show netdestination wan-ip verbose
    
    Name: wan-ip
    Destination ID: 72
    
    
    Position Type IP addr Mask-Len/Range
    -------- ---- ------- --------------
    1 override vlan 100 offset 1
    2 override vlan 100
    
    
    Destination ID = 72, start-index = 1048
    1048: 4 24.4.38.1 255.255.255.255
    1049: 4 24.4.38.0 255.255.254.0

     

    It sounds like my best option is to keep the public IP in my ACLs and look into getting a static IP from my ISP or figure out a solution to update the controller's netdestination automatically.



  • 8.  RE: Port Forwarding Issue

    Posted Apr 30, 2019 03:35 PM

    The public subnet is a /23 and you will get a random IP. I agree with you that the best way for now is to use the public directly in the ACL



  • 9.  RE: Port Forwarding Issue

    Posted Jun 16, 2019 03:52 PM

    @krispygrimace wrote:

    It sounds like my best option is to keep the public IP in my ACLs and look into getting a static IP from my ISP or figure out a solution to update the controller's netdestination automatically.


    You could use the ArubaOS API to automatically update your controller's netdestination.  Check out https://github.com/ravishivt/arubaos-api.  There's a sample script that does exactly this (gets current public IP and updates the controller's net destination if outdated).