DMZ - Can I RDP to it from the LAN
-
While effectively true, this is not technically accurate.
LAN->WAN is allowed via the standard LAN rule "Allow any outbound."
This would also allow LAN->DMZ traffic, but you might need a DMZ-> LAN specific rule on the DMZ tab to allow traffic back to LAN.There is no need to add any DMZ rules for outbound. Once the NAT translation has taken place and resides in the firewall states, by default return traffic is permitted.
Thanks for replies.
Are you saying that as standard, he can just RDP from his PC on 192.168.0.20 directly to 172.16.0.100 (assuming windows firewall on server allows it)?
-
Assuming both pfSense and your Windows firewall(s) allow it - it should just work. And of course they both should be using pfSense as their gateway…
-
This isn't working ie. can't RDP to 172.16.0.20 but both systems are connected through the pfsense as their gateway.
To give me some clues - I can't see anything blocked in the firewall system status, so assume this isn't a firewall rule problem but something more fundamental.
I have set the LAN and DMZ to both allow private and bogon networks.Do I need to set a NAT rule (outbound or forward) or should I look elsewhere?
I did test by setting a port forward from WAN1 to the DMZ server and can RDP from a machine on the internet to WAN1, so the problem isn't a local firewall on the server.
thanks
-
You shouldn't need any outbound rules or NAT rules for this really. Are you able to ping 172.16.0.20 from the 192.168.0.20 subnet? If you run a tracert, at what point does this fail?
-
You shouldn't need any outbound rules or NAT rules for this really. Are you able to ping 172.16.0.20 from the 192.168.0.20 subnet? If you run a tracert, at what point does this fail?
OK - from reading other threads on here, they suggested that you couldn't ping across to PCs in the DMZ. However I can ping the interface of the DMZ:
C:\Build>ping 172.16.0.254Pinging 172.16.0.254 with 32 bytes of data:
Reply from 172.16.0.254: bytes=32 time<1ms TTL=64
Reply from 172.16.0.254: bytes=32 time<1ms TTL=64
Reply from 172.16.0.254: bytes=32 time<1ms TTL=64
Reply from 172.16.0.254: bytes=32 time<1ms TTL=64
C:\Build>ping 172.16.0.20Pinging 172.16.0.20 with 32 bytes of data:
Request timed out.C:\Build>tracert 172.16.0.254
Tracing route to 172.16.0.254 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 172.16.0.254
C:\Build>tracert 172.16.0.20
Tracing route to 172.16.0.20 over a maximum of 30 hops
1 17 ms 18 ms 18 ms 85-210-250-xx.dynamic.dsl.as9105.com
OK so do I have a routing issue as it's obviously going out onto the internet to find this PC?
thanks again
-
Yes it looks like it, but I have no idea why!? You don't have any static routes or anything set up anywhere do you? Do you have any other nodes on the 172.16.0.0 subnet?
If you run a ping from pfSense > Diganostics > Ping to 172.16.0.20 do you get a response?
Jonathan.
-
Why don't you past up your interfaces and your rules for these lan and dmz..
Lets be clear here, there is no NAT required to talk between 2 lan interfaces on pfsense. And you pinging the dmz interface of pfsense proves what exactly?? Do you have a firewall rule to block that??
Where did you do that traceroute from?? Pfsense?
Also how do you have this connected to pfsense.. Are you using different switches? Or do you have some unmanaged switched connected to both your lan and dmz interfaces? Is dmz a vlan?
-
Yes it looks like it, but I have no idea why!? You don't have any static routes or anything set up anywhere do you? Do you have any other nodes on the 172.16.0.0 subnet?
If you run a ping from pfSense > Diganostics > Ping to 172.16.0.20 do you get a response?
Jonathan.
OK varied results pinging from pfsense to the server on the DMZ:
_PING 172.16.0.20 (172.16.0.20): 56 data bytes
64 bytes from 172.16.0.20: icmp_seq=0 ttl=128 time=0.398 ms
64 bytes from 172.16.0.20: icmp_seq=1 ttl=128 time=0.335 ms
64 bytes from 172.16.0.20: icmp_seq=2 ttl=128 time=0.400 msPING 172.16.0.20 (172.16.0.20) from 192.168.0.254: 56 data bytes
64 bytes from 172.16.0.20: icmp_seq=0 ttl=128 time=0.482 ms
64 bytes from 172.16.0.20: icmp_seq=1 ttl=128 time=0.405 ms
64 bytes from 172.16.0.20: icmp_seq=2 ttl=128 time=0.364 msPING 172.16.0.20 (172.16.0.20) from 127.0.0.1: 56 data bytes
–- 172.16.0.20 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss_
I guess this is what I expect but this does imply a route through from 192.168.0 to 172.16.0 -
Why don't you past up your interfaces and your rules for these lan and dmz..
Lets be clear here, there is no NAT required to talk between 2 lan interfaces on pfsense. And you pinging the dmz interface of pfsense proves what exactly?? Do you have a firewall rule to block that??
Where did you do that traceroute from?? Pfsense?
Also how do you have this connected to pfsense.. Are you using different switches? Or do you have some unmanaged switched connected to both your lan and dmz interfaces? Is dmz a vlan?
Thanks for the reply John.
Interfaces (I hope this is what you mean) and rules attached. The tracert is from my PC on the 192.168.0.0 network. That network is connected via a switch but there are no Vlans at all. The DMZ is actually connected from the pfsense directly into a VM host which is hosting the server. This server in VMware is set to the relevant ethernet port that is connected to the DMZ interface on the pfsense.
 -
Dude why do you think you need to add a route???
Pfense has both of these networks directly attached = it knows how to get there!!! Ie routes already… Look in your routing table.
diag, routes... What do you see... Here is mine for example, I have multiple local networks, that can talk if I allow it.. Or not if I block it in the firewall rules created.
See all the 192.168.2, .3, .4, .5, .9 /24s
edit: "The tracert is from my PC on the 192.168.0.0 network."
Well you go something odd going on then... Since your first hop should be pfsense... Here is traceroute to a box on one of my other segments.
C:>tracert 192.168.2.50
Tracing route to brother.local.lan [192.168.2.50]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms pfSense.local.lan [192.168.9.253]
2 2 ms 2 ms 2 ms brother.local.lan [192.168.2.50]Trace complete.
That is from a box on 192.168.9.0/24 see it hits its gateway and then goes out the 192.168.2/24 network that also directly attached to pfsense.
I see your problem - your setting specific GATEWAYS!! You need rules above your gateway rules to allow your traffic… I have to head to work, but I can show you examples in a bit.. This is a very common user mistake and there plenty of threads about this.. MULTIPLE!!!
-
dude my gateway is not .254 its .253 which is pfsense IP address in those networks.
Why would I see an arp entry in 192.168.9.0 for a 172 network or in my case 192.168.x
Your problem is your lan rules FORCE traffic to go out some wan gateway… Which NO can not get to your other local networks.
Create a rule above that allows your traffic for that network.. Your not even doing failover correctly..
Here
https://doc.pfsense.org/index.php/Multi-WAN
Policy Route NegationWhen a firewall rule directs traffic into the gateway, it bypasses the routing table on the firewall. Policy route negation is just a rule that passes traffic to other local or VPN-connected networks that does not have a gateway set. By not setting a gateway on that rule it will bypass the gateway group and use the routing table on the firewall. These rules should be at the top of the list – or at least above any rules using gateways.
do you have a gateway group created? If you want all traffic to go out 1 gateway you would set that as teir 1, if you then want the other wans to be used you would put them in different tiers. Did you read the multi-wan doc?
-
dude my gateway is not .254 its .253 which is pfsense IP address in those networks.
Why would I see an arp entry in 192.168.9.0 for a 172 network or in my case 192.168.x
Your problem is your lan rules FORCE traffic to go out some wan gateway… Which NO can not get to your other local networks.
Create a rule above that allows your traffic for that network.. Your not even doing failover correctly..
Here
https://doc.pfsense.org/index.php/Multi-WAN
Policy Route NegationWhen a firewall rule directs traffic into the gateway, it bypasses the routing table on the firewall. Policy route negation is just a rule that passes traffic to other local or VPN-connected networks that does not have a gateway set. By not setting a gateway on that rule it will bypass the gateway group and use the routing table on the firewall. These rules should be at the top of the list – or at least above any rules using gateways.
do you have a gateway group created? If you want all traffic to go out 1 gateway you would set that as teir 1, if you then want the other wans to be used you would put them in different tiers. Did you read the multi-wan doc?
OK John I think that has set me in the right direction. And it's been a long time since someone called me dude!
Thanks for your help, I think the firewall rule/gateway group thing is crucial - I do have groups defined for failover which do seem to work, but will look more at this as you think it's setup wrongly. But the rule at the top has sent the traffic into the DMZ - so far so good….
-
You really should only need 1 rule on your lan interface pointing to wan group. Your settings in your wan group would determine which one(s) are used be it for load balancing or failover.. I don't really see the point of multiple allow rules for the different wan interfaces.
You need to place a rule before you send traffic out a gateway, if you plan on making more local networks you might want to create an alias that is either all rfc1918 address space or just your local networks and put an allow rule in before you hit your gateways.
So when your going to something local this rule will allow that traffic, and will never get to your gateway rules. When your going to something that is not local, it will hit your gateway rule and use the gateway(s) you have setup to get to say google.com, etc.
Is that clear dude ;) heheheh
-
Just to say thanks for everyone's input and help, especially John and Jon.
