Wireless Access

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?

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.

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?

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

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.

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.

Thanks @willembargeman!  I tried the VLAN offset approach and it's pretty clever but not sure if it's a perfect solution for my use case.  My public IP is 24.4.39.46 but the calculated offset address is 24.4.38.1.  I could instead use `network vlan 100` in my netdestination, which would be a match in my ACLs.  But then my worry is what if my internal clients want to reach another host on that public subnet and they always get port-forwarded.

 

 

#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.

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

---

@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).