Nat does not work with IP pool
-
@viragomann said in Nat does not work with IP pool:
@aadrem said in Nat does not work with IP pool:
The second one that has a pool of public static IP addresses.
I configured the pool with virtual IP Addresses.Each out of the pool as a virtual IP?
I do not know if I have correctly understood.
About the second internet connection I have two WAN (IP_SOLO and MULTI_IP):
- MULTI_IP is the pool; I have 6 Public IP addresses one configured directly with WAN_MULTI_IP and the others five with virtual IP.
I configured a VLAN too in which I put one windows server (the purpose is to accede to this machine with an RDP connection being sure that it is isolated by my LAN network).
Does the server have internet access, presumed it is permitted by firewall rules?
The server has internet access, and it works without any problem and its firewall is configured correctly (the ports are opened).
There is something strange too if I try to create an RDP connection using the public IP with a computer in the LAN it works but if I try to create an RDP connection using the public IP with a computer that is ubicated in other office (with a different router and internet connection) it does not work.
Note that RDP also needs UDP. So change the protocol in the NAT rule to TCP/UDP.
Yes I know, I have already tried to open both TCP and UDP but the result still being the same.
Which pfSense version are you on?
I am using PFSense 2.6.0-RELEASE
-
@aadrem said in Nat does not work with IP pool:
Note that RDP also needs UDP. So change the protocol in the NAT rule to TCP/UDP.
Yes I know, I have already tried to open both TCP and UDP but the result still being the same.
So since your firewall rule seems to be associated with the NAT rule you should now see also the TCP/UDP protocol there.
One possible reason for not working secondary WAN access can be firewall rules on an interface group or floating rules. Do you have any of these?
If not it should basically work.
To investigate, I'd suggest to run a packet capture on the WAN interface to check if the packets arrive there and if you see correct responses. If you see requests packets, but no responses, capture the LAN side traffic to see if your server is responding properly.BTW: Generally it's not recommended to open RDP ports to the public internet. You shold better use VPN. But if it is meant for a unique or certain source IPs you can do that and limit the source in your rule accordingly.
-
@viragomann said in Nat does not work with IP pool:
So since your firewall rule seems to be associated with the NAT rule you should now see also the TCP/UDP protocol there.
Yes, as you can see the rule is updated.
One possible reason for not working secondary WAN access can be firewall rules on an interface group or floating rules. Do you have any of these?
I had a floating rule that I disabled but the result does not change.
I do not have an interface group, but I have a gateway group (I used it to manage the failover connection).If not it should basically work.
To investigate, I'd suggest to run a packet capture on the WAN interface to check if the packets arrive there and if you see correct responses. If you see requests packets, but no responses, capture the LAN side traffic to see if your server is responding properly.I used the packet capture on the WAN interface, and this is the result:
17:28:00.335081 IP 151.xx.xx.xxx.51257 (IP request from the other place) > 151.xx.xxx.xxx.3389: tcp 0 (Pubic IP associated to my windows server)
So, there is no response I can see various requests but no one answer.
After that I tried the packet capture on the LAN and this Is the result:
17:16:35.080671 IP 151.xx.xx.xxx.50847 (IP request from the other place) > 192.168.15.7.3389: tcp 0 (My local IP address of the windows machine)
17:16:35.081423 IP 192.168.15.7.3389 > 151.xx.xx.xxx.50847: tcp 0
17:16:36.089578 IP 192.168.15.7.3389 > 151.xx.xx.xxx.50847: tcp 0In this case I see the answer, but I cannot understand why this answer do not arrive online.
I am really confused about why it is not working. It should but it does not.
I am still checking in this web https://www.yougetsignal.com/tools/open-ports/ putting the public IP and the port and the web advises me that the port result closed.
BTW: Generally it's not recommended to open RDP ports to the public internet. You shold better use VPN. But if it is meant for a unique or certain source IPs you can do that and limit the source in your rule accordingly.
I know that it is not recommended to use a public rdp connection in fact I would like to open the port only for a specific public IP but, before of that I want check that the rule is working. By the way thank you for your advice.
-
@aadrem said in Nat does not work with IP pool:
I used the packet capture on the WAN interface, and this is the result:
17:28:00.335081 IP 151.xx.xx.xxx.51257 (IP request from the other place) > 151.xx.xxx.xxx.3389: tcp 0 (Pubic IP associated to my windows server)Obviously some noise here. Set the port filter to get RDP packets only.
Possibly the rule is not applied to the RDP packets.
Check this out please by enabling the logging in the associated firewall rule. Then try an RDP connection and check the firewall log after and look for the concerned rule name. -
@viragomann said in Nat does not work with IP pool:
@aadrem said in Nat does not work with IP pool:
I used the packet capture on the WAN interface, and this is the result:
17:28:00.335081 IP 151.xx.xx.xxx.51257 (IP request from the other place) > 151.xx.xxx.xxx.3389: tcp 0 (Pubic IP associated to my windows server)Obviously some noise here. Set the port filter to get RDP packets only.
Possibly the rule is not applied to the RDP packets.
Check this out please by enabling the logging in the associated firewall rule. Then try an RDP connection and check the firewall log after and look for the concerned rule name.Yes, I do not know very well all the features of pfsense, but with your advice I am understanding something more.
I enabled the logging of the rule and here the result:
It seems to work correctly. The main point is that it seems that the problem is with outbound connection.
I am able to contact my windows server, but it is not able to answer me. -
@aadrem
Yes, seems the rule is applied correctly. I had concerns, because you're accessing a non-default WAN interface from the outside. That pfSense replies properly on this interface requires that pfSense add the reply-to tag to the connection. This is done by the firewall rule, which is permitting the access, and is only applied if the interface is unique.
So it doesn't work with rules on interface groups as well as with floating rules. Also it didn't work on a former pfSense release.
Therefore I was asking many questions.reply-to also requires that the interface, which the packet is entering pfSense, has a gateway stated in the interface settings. Is this the case?
If one of these requirements is not met, replies go out to the default gateway, which would be the other interface.
So to get sure, that this is not the case, you can take a packet capture on the other WAN while you try RDP in.But as mentioned, you WAN_MULTI_IP capture doesn't really show a long period of time. Is there truly only one RDP packet?
-
@viragomann said in Nat does not work with IP pool:
@aadrem
Yes, seems the rule is applied correctly. I had concerns, because you're accessing a non-default WAN interface from the outside. That pfSense replies properly on this interface requires that pfSense add the reply-to tag to the connection. This is done by the firewall rule, which is permitting the access, and is only applied if the interface is unique.
So it doesn't work with rules on interface groups as well as with floating rules. Also it didn't work on a former pfSense release.
Therefore I was asking many questions.reply-to also requires that the interface, which the packet is entering pfSense, has a gateway stated in the interface settings. Is this the case?
Well as you can see the WAN MULTI IP has a gateway
If one of these requirements is not met, replies go out to the default gateway, which would be the other interface.
So to get sure, that this is not the case, you can take a packet capture on the other WAN while you try RDP in.I have just done more test and here the result:
Packet capture on WAN MULTI IP:
The Windows Server receive the RDP connection through the WAN MULTI IP but does not answer.
Packet capture on VLAN in which is working the Windows server:
The windows server receives the request and it answers over the VLAN.
Packet capture on WAN (default gateway):
The Windows server answer goes through the WAN (Default gateway).
But as mentioned, you WAN_MULTI_IP capture doesn't really show a long period of time. Is there truly only one RDP packet?
Nope for that reason have added in this message the whole log.
The configuration of my gateway is:
With this gateway group:
Do you think that the problem could be related with how I am managing the gateways?
-
@aadrem
So your Windows server is responding, but the response packets are sent out to the default gateway.If all requirements I mentioned above are met, it should work.
The only pfSense version I know which behaves like that is 2.5.1.
Do you think that the problem could be related with how I am managing the gateways?
No, gateway groups do not affect the behavior how pfSense handles incoming traffic, they only affect outbound.
Yes, I do not know very well all the features of pfsense, but with your advice I am understanding something more.
I enabled the logging of the rule and here the result:Open the firewall rule for editing and note the Tracking ID and check if the same is shown in the firewall log.
-
@viragomann said in Nat does not work with IP pool:
@aadrem
So your Windows server is responding, but the response packets are sent out to the default gateway.If all requirements I mentioned above are met, it should work.
The only pfSense version I know which behaves like that is 2.5.1.
Do you think that the problem could be related with how I am managing the gateways?
No, gateway groups do not affect the behavior how pfSense handles incoming traffic, they only affect outbound.
Yes, I do not know very well all the features of pfsense, but with your advice I am understanding something more.
I enabled the logging of the rule and here the result:Open the firewall rule for editing and note the Tracking ID and check if the same is shown in the firewall log.
I feel so stupid... I checked the advance configuration of PF sense and I discovered that reply-to was disable in that section.
I removed this limitation and now it is perfectly working.
Thank you for your advices, without your help and the explication of reply-to feature it would have been impossible for me to solve this problem.
-
@aadrem said in Nat does not work with IP pool:
I checked the advance configuration of PF sense and I discovered that reply-to was disable in that section.
To be honest, I didn't think of this option, since it isn't disabled by default.
But I'm glad that you got it working.