Got a NAT / Firewall / vShield Edge brainfart (aka can't get the basics right)
jibbajabba
Member Posts: 4,317 ■■■■■■■■□□
I must be bloody dense right now, but let's start anyway.
Ok, my lab has currently multiple networks.
External VLAN : 192.168.1.0/24
Internal "Clients" VLAN: 192.168.13.0/24
At the moment I am using "ClearOS" as gateway / router between those two VLANs.
Diving into vEverything, I may as well use vShield Edge (given that I am working with vCloud Director anyway).
But I seem to have forgotten the basics of NAT / Firewalling.
The VSE Gateway got two zones configured, Internal and External (obviously)
There is one test VM connected to the test VLAN. This test VM got the IP
192.168.13.100 (first IP of the DHCP lease)
Two requirements.
1. The VM needs to be able to get "out"
2. I need to be able to RDP into the VM
So I setup two NAT rules, one SNAT (to get out) and one DNAT (to get in)
Next firewall rules. As you can see - default is to Deny ...
First I did was setting up a general Outbound rule, so anything from the internal network can get to the internet. - that works (the Test-VM object is the VM using its internal IP 192.168.13.100)
SSH is enabled for all directions (just a lab so doesn't really matter)
Now the Remote Desktop rule. Using external > internal works .. I can RDP from the 192.168.1.x network to the server in the 192.168.13.x network.
As you can see in screenshot #1 - internal is indeed the 192.168.13.x network
But when I change the "internal" object to be directly "Test-VM" again with its direct IP 192.168.13.100 - it doesn't ...
Am I losing it ?
Ok, my lab has currently multiple networks.
External VLAN : 192.168.1.0/24
Internal "Clients" VLAN: 192.168.13.0/24
At the moment I am using "ClearOS" as gateway / router between those two VLANs.
Diving into vEverything, I may as well use vShield Edge (given that I am working with vCloud Director anyway).
But I seem to have forgotten the basics of NAT / Firewalling.
The VSE Gateway got two zones configured, Internal and External (obviously)
There is one test VM connected to the test VLAN. This test VM got the IP
192.168.13.100 (first IP of the DHCP lease)
Two requirements.
1. The VM needs to be able to get "out"
2. I need to be able to RDP into the VM
So I setup two NAT rules, one SNAT (to get out) and one DNAT (to get in)
Next firewall rules. As you can see - default is to Deny ...
First I did was setting up a general Outbound rule, so anything from the internal network can get to the internet. - that works (the Test-VM object is the VM using its internal IP 192.168.13.100)
SSH is enabled for all directions (just a lab so doesn't really matter)
Now the Remote Desktop rule. Using external > internal works .. I can RDP from the 192.168.1.x network to the server in the 192.168.13.x network.
As you can see in screenshot #1 - internal is indeed the 192.168.13.x network
But when I change the "internal" object to be directly "Test-VM" again with its direct IP 192.168.13.100 - it doesn't ...
Am I losing it ?
My own knowledge base made public: http://open902.com
Comments
-
Essendon Member Posts: 4,546 ■■■■■■■■■■So what happened with this bud? I havent worked with Edge so I cant say anything about its config, but it looks good from what you've posted.
-
jibbajabba Member Posts: 4,317 ■■■■■■■■□□Opened a ticket. I had a few colleagues checking and it should work. Unless we all miss somethingMy own knowledge base made public: http://open902.com
-
Essendon Member Posts: 4,546 ■■■■■■■■■■Fair enough, let us know how/what they worked on to resolve this.
-
jibbajabba Member Posts: 4,317 ■■■■■■■■□□Hello Michael,
I am emailing regarding your support request 14451317803 for an issue when configuring firewall and NAT rules on a vShield Edge using vShield Manager.
I have been reviewing your description and the screenshots which you provided.
From this my understanding is that the RDP connection is not working when you are using a firewall rule to allow Remote Desktop from 'External' sources to an internal VM with an internal IP address of 192.168.13.100.
However if you change the rule to allow RDP traffic from 'External' source to 'Internal' destination you see that the RDP is working correctly.
Following on from your description it did not make sense to me either that these two rules would behave differently. Indeed I went ahead and recreated in a test environment a similar setup with a vShield Edge between two networks. In my environment I have a DNAT rule to translate from an external IP to the VM's internal IP.
In my firewall then I also have deny as the default rule.
In my environment I was testing the connection to the VM by going to the external address. So for example I have a DNAT rule translating from the External IP of 192.168.2.40 to the VM's internal IP of 172.10.90.102. I then try and reach the VM by going to the external IP 192.168.2.40. Therefore I need a firewall rule to allow External access to IP of 192.168.2.40. This succeeds.
If I were to change the rule to External access to IP of 172.10.90.102 I cannot reach the VM any longer as the firewall is taking precedence over the DNAT rule.
If now though I change the rule from allow External to Internal I see that on connecting to 192.168.2.40 the internal VM is still reachable which contradicts the behaviour of the rule above with External to Internal IP of 172.10.90.102.
It is as if the DNAT rule is taken into account when using the Object approach. The Objects, "External" and "Internal", represent the actual network interfaces on the vShield Edge. It seems to me that the Edge is taking into account that the destination of the packet is actually on the Internal interface and so should be allowed.
I am not sure however if this is indeed the case. As such I have opened channels internally here to get clarification. In the meantime I believe that you should use a firewall rule allowing access from External to the External DNAT IP as this should be the IP you wish to access rather than the internal IP.
Please let me know if my understanding is incorrect or if you have any questions. I will get confirmation on the behaviour internally and update you when I have further info.
Will test later ..My own knowledge base made public: http://open902.com