Problems accessing internal server on wan port
-
Hi…
Not sure if this will help.
Are you blocking ICMP ping request? (udp)H.
-
-
Steve..
Thanks for the correction…
My thought is there - but I made a mistake...H.
-
Reading through this thread again several things occur to me.
Why are you using the pfSense box at all?You shouldn't be using NAT at all if you want to be able to access the servers individually. You want the pfSense box to just route. Perhaps restrict access later when that is working.
You need to set a firewall rule on WAN, something like allow traffic from 192.168.0.0/24 to any on any protocol. Or even from any just to get things working.
You can access DC from DC1 because DC1 sends all traffic to pfSense as it's gateway and pfSense sends traffic to your firewall. Your firewall has a route to DC because of the VPN.
From DC there is no route to DC1. The branch firewall has no knowledge of the subnet behind pfSense.
You will need to add a route to the branch firewall so I knows where to send traffic. I have virtually no Cisco experience so I can't help you there.Steve
Edit: In fact to use it for routing only you will have to disable NAT entirely. See: http://forum.pfsense.org/index.php/topic,25823.0.html
-
to Steves point I was thinking this as well about layering another router in this mix.
Unless you want to setup another subnet and use the pfSense to do this?
Like a DMZ zone in front of your PIX and then pfsense subnetting? -
We are using PFSense because of its Captive Portal ability. This particular feature works flawlessly.
We have attempted to disable the firewall portion of PFSense and as the documentation states, PFSense will just be routing. However, when we "disable firewall", PFSense doesn't allow any traffic through whether its outgoing or incoming.Your point on adding a rule to the branch office firewall is definitely worth looking at.
I figured that I will try basic port forwarding before solving this overall issue that we are experiencing.
Via our WAN port, I am now attempting to forward port 389 (LDAP) to our internal server at 192.168.1.2. Please see my configuration below.
Nat Reflection - Enabled
NAT Rules
Firewall Rules
Firewall Configuration Page
http://img98.net/show.php/408418_RuleSetupPage.jpg.htmlTechnically, this should at least work. I am using an LDAP application and connecting directly to the wAN IP of our PFSense box (192.168.3.100) on port 389. PFSense should at least be able to forward this traffic to the 192.168.1.2 address using port 389 however it does not.
-
Destination address should be WAN address. That's what incoming packets will be addressed to.
See: http://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F
Steve
-
Not sure if I am wrong now, but the source port in the firewall rule shouldn't be 389. It should be "any" ( * ).
-
As I read that post I thought, yes it should be any, the source port can be any random port. Then I began to doubt myself. ::)
However I'm pretty sure that the port forwarder doesn't change the source port.Either way the incoming packets will be passed by the any any any any rule.
Steve
-
Thank you everyone for the advice. Changing the destination address to WAN address allowed us to forward traffic. At least we know that all "can" work.
Now back to working our first issue. I advised the following, which was pretty much in line with Steve's comment:
There are several issues here, mixed into one.
If DC2 can ping DC1, but not the other way around, then it is likely that the pfSense firewall is doing masquerading for the 192.168.1.0/24 network behind it. This would result in a situation where in the rest of the network the packets originating from DC2 actually look as if they originated on 192.168.3.100. When they get back there, the firewall captures them, performs the de-masquerade and all is good.
However, this now creates a problem, because to the world outside of 192.168.1.0/24, that network has become unroutable. Since all networks involved are private networks anyway, I would suggest to remove the masquerading and rather just have a firewall and some proper routing.
The Rv082(A) has no knowledge of the existence of the 192.168.1.0/24 network, since it is hidden behind the pfSense firewall. So the first thing to do is put a static route into that device telling it to route all traffic for 192.168.1.0/24 into the VPN tunnel.
Now make sure that in the pfSense firewall you only have the necessary filters in place and all NATting is disabled.
If for whatever reason you cannot or do not want to remove the masquerading, you will have to create port forwarding rules in the pfSense for every single device and service that must be reachable from the outside. And you need to run split DNS, because the same names now have to resolve to different IP addresses depending on where the client is. This can get very messy very quickly and I would recommend not to do unless there really is no other choice.
If you don't like static routing, you could also enable RIP or OSPF in pfSense (not sure whether it has these features) and in the RV082 devices (if they have it), but then this answers is going to get a whole lot longer, so try static routing first.
-
Would configuring pfSense as a transparent bridge solve our issues here? I completed a bit more research on the topic.
-
Running pfsense as a transparent bridge would certainly work but it's a far more difficult configuration to achieve. If you've done some research you'll have found posts from people struggling to get it right.
If you feel confident try it.Steve
