DMZ - Can I RDP to it from the LAN

[jonathanbaird]

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…

[robatwork]

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

[jonathanbaird]

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?

[robatwork]

@jonathanbaird:

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.254

Pinging 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.20

Pinging 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

[jonathanbaird]

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.

[johnpoz]

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?

[robatwork]

@jonathanbaird:

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 ms

PING 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 ms

PING 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

[robatwork]

@johnpoz:

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.


[johnpoz]

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!!!

[johnpoz]

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 Negation

When 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?

[robatwork]

@johnpoz:

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 Negation

When 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….

[johnpoz]

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

[robatwork]

Just to say thanks for everyone's input and help, especially John and Jon.