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
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
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 184.108.40.206 (not in real world but obfuscated for privacy).
show datapath session table | include 9443
192.168.1.22 220.127.116.11 6 61501 9443 1/0 0 24 0 0/0/1 3 1 64 YC 6
18.104.22.168 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.
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 22.214.171.124 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.
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 126.96.36.199 but the calculated offset address is 188.8.131.52. 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
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 184.108.40.206 255.255.255.255
1049: 4 220.127.116.11 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).
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.