Wireless Access

last person joined: 22 hours ago 

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

Odd address translation happening from trusted physical port to un-trusted VLANs

This thread has been viewed 1 times

  • 1.  Odd address translation happening from trusted physical port to un-trusted VLANs

    Posted Aug 02, 2012 10:06 PM

    I have one physical trusted interface GE1/2 feeding a switch in our datacenter with one trusted VLAN running on that port.  Its IP is 172.17.2.1 All my other VLANs are untrusted and configured for RAPs and their respective subnets.

    All our servers hang off that trusted GE1/2 port and are in the 172.17.2.0/24 subnet.  The best way to describe you what is happening is to show you a condensed output of netstat on one of our exchange servers. 

     

    Active Connections

  Proto  Local Address          Foreign Address        State

  TCP    172.17.2.65:56819      172.17.2.1:49244       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49248       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49254       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49257       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49284       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49351       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49353       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49457       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49458       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49483       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49487       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49583       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49588       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49717       ESTABLISHED
  TCP    172.17.2.65:56819      172.17.2.1:49718       ESTABLISHED

     

    Those foriegn addresses are all different clients on different VLANs hung of RAPs on different subnets.  Basically any thing on any other VLAN that communicates back to any thing on this 172.17.2.0/24 network has its source address translated and appears as if it is coming from the default gateway address of that subnet.  It has to be some sort of address translation between VLANs as everything still communicates properly, I just can't see the actual IP of the internal clients on different VLANs talking to it.   This translation is not occuring between any of the the other RAP VLANs to eachother.  I can plainly see their source IPs from one to the other.  

     

    This issue wreaks havoc on quite a lot of things especially with System Center and trying to watch any type of log.  All I ever see is 2.1.  :manmad:

     

    I'm happy to provide extra info and settings and what not but I'm hoping someone immediatley understands and knows whats going on.

     

    Thanks!!



  • 2.  RE: Odd address translation happening from trusted physical port to un-trusted VLANs

    EMPLOYEE
    Posted Aug 02, 2012 10:52 PM

    Make sure you don't have "ip nat inside" on that vlan interface



  • 3.  RE: Odd address translation happening from trusted physical port to un-trusted VLANs

    Posted Aug 02, 2012 11:22 PM

    Thanks for quick reply.  I just checked the configuration and I have "ip nat inside" on every single one of my vlan interfaces except the one I use as the uplink on the controller.

     

    When I uncheck "Enable source NAT for this VLAN" in the web-client to disable "ip nat inside" on that vlan then my servers no longer natted behind the controller's IP and that server subnet started hitting the inside of my firewall that the controller sits under.  I still need that private server subnet 172.17.2.0/24 source natted so it has external connectivity through the controller's IP and is hidden behind it.

     

     

     

     



  • 4.  RE: Odd address translation happening from trusted physical port to un-trusted VLANs

    EMPLOYEE
    Posted Aug 03, 2012 12:02 AM

    Is there any way to have the upstream firewall doing the natting, instead?  if you do "ip nat inside" on an  ip interface, that is the NAT boundary.



  • 5.  RE: Odd address translation happening from trusted physical port to un-trusted VLANs

    Posted Aug 03, 2012 04:33 AM

    Wow, that's like getting hit in the head with a brick, not sure how to even answer.  I'll have to do some experimenting with nat off and see how bad it breaks things.  We are fully deployed with session acls between each VLAN, split tunneled on all the RAPs, port forwarding with NAT pools, VIA, the list goes on.  I think that would impact pretty much the entire configuration.

     

    I guess that's why my session acls didn't seem to work and I would basically have to have a rule on each side of each VLAN for one to talk back and forth to the other... 

     

    Could I maybe just turn of natting at the interface and do it policy based?  Pros/Cons to that?

     

    Thanks



  • 6.  RE: Odd address translation happening from trusted physical port to un-trusted VLANs

    EMPLOYEE
    Posted Aug 03, 2012 07:38 AM
    @dcc24 wrote:

    Wow, that's like getting hit in the head with a brick, not sure how to even answer.  I'll have to do some experimenting with nat off and see how bad it breaks things.  We are fully deployed with session acls between each VLAN, split tunneled on all the RAPs, port forwarding with NAT pools, VIA, the list goes on.  I think that would impact pretty much the entire configuration.

     

    I guess that's why my session acls didn't seem to work and I would basically have to have a rule on each side of each VLAN for one to talk back and forth to the other... 

     

    Could I maybe just turn of natting at the interface and do it policy based?  Pros/Cons to that?

     

    Thanks

    If you are fully deployed and you have this one crucial problem, you should either contact support or your local Aruba Engineer.

     

     They would be able to get the FULL details of your network and advise you best without exposing you to downtime.