PFSense implementation help…
-
Ah sorry, that
l teach me to jump in size 12s 1st…Netstat -r -n gives...
$ netstat -r -n
Routing tablesInternet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.1 UGS 0 2 fxp0
77.101.88.211 127.0.0.1 UGHS 0 0 lo0
127.0.0.1 127.0.0.1 UH 3 0 lo0
192.168.1.0/24 link#2 UC 0 0 re0
192.168.1.100 00:0e:0c:63:a5:ff UHLW 1 116 re0 1200
192.168.1.244 127.0.0.1 UGHS 0 0 lo0
192.168.2.0/24 link#3 UC 0 0 re1
192.168.100.10 127.0.0.1 UGHS 0 0 lo0Internet6:
Destination Gateway Flags Netif Expire
::1 ::1 UHL lo0
fe80::%fxp0/64 link#1 UC fxp0
fe80::250:8bff:fed9:b946%fxp0 00:50:8b:d9:b9:46 UHL lo0
fe80::%re0/64 link#2 UC re0
fe80::214:78ff:fe7e:ccd5%re0 00:14:78:7e:cc:d5 UHL lo0
fe80::%re1/64 link#3 UC re1
fe80::20a:ebff:fe2f:ed6f%re1 00:0a:eb:2f:ed:6f UHL lo0
fe80::%lo0/64 fe80::1%lo0 U lo0
fe80::1%lo0 link#4 UHL lo0
ff01:1::/32 link#1 UC fxp0
ff01:2::/32 link#2 UC re0
ff01:3::/32 link#3 UC re1
ff01:4::/32 ::1 UC lo0
ff02::%fxp0/32 link#1 UC fxp0
ff02::%re0/32 link#2 UC re0
ff02::%re1/32 link#3 UC re1
ff02::%lo0/32 ::1 UC lo0here
s whats in the firewall log...Act Time If Source Destination Proto
Feb 27 14:45:10 WAN 118.71.68.55:59413 77.101.88.21:39303 UDP
Feb 27 14:45:12 WAN 118.71.68.55:59413 77.101.88.21:39303 UDP
Feb 27 14:45:16 WAN 118.71.68.55:59413 77.101.88.21:39303 UDP
Feb 27 14:45:28 WAN 92.237.197.60:38575 77.101.88.21:39303 UDP
Feb 27 14:45:45 WAN 213.167.21.3:13087 77.101.88.21:39303 UDP
Feb 27 14:45:47 WAN 213.167.21.3:13087 77.101.88.21:39303 UDP
Feb 27 14:45:52 WAN 213.167.21.3:13087 77.101.88.21:39303 UDP
Feb 27 14:45:58 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:45:58 BRIDGE0 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:45:58 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:46:18 WAN 213.167.22.144:27617 77.101.88.21:39303 UDP
Feb 27 14:46:20 WAN 213.167.22.144:27617 77.101.88.21:39303 UDP
Feb 27 14:46:21 LAN 192.168.1.30:138 192.168.1.255:138 UDP
Feb 27 14:46:21 BRIDGE0 192.168.1.30:138 192.168.1.255:138 UDP
Feb 27 14:46:21 LAN 192.168.1.30:138 192.168.1.255:138 UDP
Feb 27 14:46:22 WAN 83.228.56.143:2040 77.101.88.21:39303 UDP
Feb 27 14:46:24 WAN 213.167.22.144:27617 77.101.88.21:39303 UDP
Feb 27 14:46:25 WAN 83.228.56.143:2040 77.101.88.21:39303 UDP
Feb 27 14:46:31 WAN 83.228.56.143:2040 77.101.88.21:39303 UDP
Feb 27 14:47:05 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:05 BRIDGE0 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:05 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:13 LAN 192.168.1.30:137 192.168.1.255:137 UDP
Feb 27 14:47:13 BRIDGE0 192.168.1.30:137 192.168.1.255:137 UDP
Feb 27 14:47:13 LAN 192.168.1.30:137 192.168.1.255:137 UDP
Feb 27 14:47:14 LAN 192.168.1.30:137 192.168.1.255:137 UDP
Feb 27 14:47:14 BRIDGE0 192.168.1.30:137 192.168.1.255:137 UDP
Feb 27 14:47:14 LAN 192.168.1.30:137 192.168.1.255:137 UDP
Feb 27 14:47:14 LAN 192.168.1.30:137 192.168.1.255:137 UDP
Feb 27 14:47:14 BRIDGE0 192.168.1.30:137 192.168.1.255:137 UDP
Feb 27 14:47:14 LAN 192.168.1.30:137 192.168.1.255:137 UDP
Feb 27 14:47:23 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:23 BRIDGE0 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:23 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:36 WAN 87.121.155.16:11656 77.101.88.21:39303 UDP
Feb 27 14:47:38 WAN 87.121.155.16:11656 77.101.88.21:39303 UDP
Feb 27 14:47:42 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:42 BRIDGE0 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:42 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:42 WAN 87.121.155.16:11656 77.101.88.21:39303 UDP
Feb 27 14:47:44 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:44 BRIDGE0 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:44 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:47 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:47 BRIDGE0 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:47:47 WAN 10.5.128.1:67 255.255.255.255:68 UDP
Feb 27 14:48:02 WAN 212.30.33.69:38612 77.101.88.21:39303 UDP
Feb 27 14:48:04 WAN 123.16.35.227:21135 77.101.88.21:39303 UDP
Feb 27 14:48:06 WAN 123.16.35.227:21135 77.101.88.21:39303 UDP
Feb 27 14:48:12 WAN 123.16.35.227:21135 77.101.88.21:39303 UDPand my interfaces are....
WAN interface (fxp0)
LAN interface (re0)
DMZ interface (re1)My DMZ (re1) is not connected at the moment
-
There are some strange things you have reported:
$ netstat -r -n
Routing tablesInternet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.1 UGS 0 2 fxp0Your default gateway has a private IP address on your LAN subnet and is accessed through your WAN interface? How is that going to work?
here
s whats in the firewall log…Act Time If Source Destination Proto
. . .
Feb 27 14:45:58 BRIDGE0 10.5.128.1:67 255.255.255.255:68 UDPWhat is this BRIDGE0 interface? It doesn't show up in anything you have previously provided.
-
The bridge0 interface, I don`t know, I thought it was supposed to be there!?! ??? ??? :o
The default gateway, should that not be the address of the interface to get off the LAN??
That
s what its set to on my IPCop now?would it matter that PFSense was not installed "in situ"? I installed it on my bench then physically installed it on the network at a later date!?
-
OK, while I
ve been waiting, Ive re-installed PFSense altogether but this time 'in situ', and its working, Im posting through it now with my MAC spoofed to that in my IPCop (I know that IP off by heart ::) ;D)It seems that this system is not an 866 it
s a 433Mhz… think its a celeron too! I give in!So up to now I
m good (well lets say better shall we ;))No doubt there
ll be many more daft questions over the coming weeks, most notably when I replace my LAN and DMZ nics for Intel pro 1000 MTsSo to WallabyBob, many thanks for all your assistance and to all who assisted, I thank you and Goodnight!
-
would it matter that PFSense was not installed "in situ"? I installed it on my bench then physically installed it on the network at a later date!?
It shouldn't matter that pfSense was installed in the system on your bench PROVIDED you made the necessary configuration adjustments when you connected it to the network.
The default gateway, should that not be the address of the interface to get off the LAN??
No, the default gateway should be the IP address of the system that is one hop closer to the default destination (the Internet). The default gateway was displayed as 192.168.1.1 which is the IP address of a system on your LAN (according to the data provided). But the route table also said those packets should go out over fxp0, your WAN interface. This is seriously inconsistent; I have no idea what FreeBSD would do with that.
-
Well, that`s certainly an odd one….
My PFSense is now on the LAN with it
s IP 192.168.1.1 and all my devices are setup with the default gateway as 192.168.1.1 and its working (obviously).The other issue(s) must have been cleared up with the reinstall.
Again though, thanks for all your help, would`ve been still stuck without you.
Time to play with OpenVPN!
;) ;D
-
The devices on the LAN (desktop pcs, laptops etc) should have their gateway set as the pfSense LAN interface.
The pfSense box itself should be using your ISP as a gateway. The gateway will be sent via DHCP when the modem first sets up the connection.Steve
-
yeah, that makes more sense.
just need to figure my way around setting up rules now, quite different from IPCop.
OpenVPN can wait a while…
-
Holy Mother of God!
Quick pointer request please…
I want to forward say port 1234 on my external to say 5678 on my DMZ how in the name of the big fella upstairs do I do this but so it works??
I`ve tried it in the NAT bit AND i the rules bit and no go...... help.....
I used this info... > http://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F
-
It's quite straight forward really but a little different to IPCop if I remember.
It's pretty much as explained in that doc you linked to.
One thing that through me is that, from a system point of view, the port forwarder is outside the firewall.
This means that your firewall rule has to allow traffic with your DMZ ip is the destination.
Have a look here.Post the settings you've made and we'll see what's up.
Steve
-
I
ve done it as per the instructions I linked to but it dont work, just times out. and yet oddly enough, if I scan the relevant port from grc.com it does show as open, if I remove/disable the rule it shows as stealth.Settings are as follows:
Interface: WAN
External Address: Any
Protocol TCP/UDP
Ext Port Range: 1234
NAT IP: 192.168.2.x
Local Port 5678Add firewall rule: Checked
As far as I can find, I have it setup correctly but it don`t work
UPDATE
I can`t get Remote desktop thru either ??? -
Ok, so it looks like the firewall rule isn't being added correctly.
What does it list under firewall rules?
Does the firewall log show your incoming forwarded requests being blocked?Steve
Edit: External address should be wan interface address
-
Hi steve, thanks again for your help….
I've tried with the external address set to wan address and set to any, neither seem to work.
something that has just dawned on me though is I'm trying to access some stuff on my DMZ from my LAN but via my external address, something that has and does work thru IPCop, but so far not with PFSense.
All attempts are blocked (little red X's) in the firewall log (I think it says default deny rule, not 100% though) and seem to originate from a 10.x.x.x address. This address scheme is seemingly what my ISP use on the cable side of the modems on their network, it is however not the address of the cable side of my CM, it's a few digits out... I have also removed the block 10/8 address rule but it still doesn't seem to work.
I can hit an FTP server on my DMZ from my LAN and that rule shows up as passed and all the address info looks correct but as sonn as I try to involve the WAN, it spits it's dummy out!
I'm using RDP on it's default port for the moment, just while troubleshooting.
Thanks again for all yor help.
-
Ah.
@BigBadAl:I'm trying to access some stuff on my DMZ from my LAN but via my external address, something that has and does work thru IPCop, but so far not with PFSense.
How exactly are you doing that?
I have run into a similar problem on a number of occasions. For example I used to run a web server in a DMZ at home. I use Dyn DNS and port forwarding so that it's accessible from the internet directly on www.viadyndnsexample.com. That all worked fine but I could not access the web server myself using that url from inside my lan. It's a routing problem, the dyn dns service returns the wan ip of my firewall and the traffic cannot be routed out through the firewall and back in again. Or something like that! :P
Suffice to say that that was true when I used IPCop and still holds for pfSense.Steve
-
I could not access the web server myself using that url from inside my lan. It's a routing problem, the dyn dns service returns the wan ip of my firewall and the traffic cannot be routed out through the firewall and back in again.
I think the problem is more like this: to access a server on a DMZ it is necessary to specify a port forward rule. That rule will typically specify the WAN interface, meaning packets arriving on the WAN interface. If the WAN interface has a public IP address then packets arriving on the LAN interface and destined to that public IP won't arrive on the WAN interface hence the port forwarding rule won't apply.
If the pfSense WAN interface has a private IP, (e.g it is downstream of a modem/router) then similar considerations may well apply to whatever port forwarding has been set up in the router.
Perhaps its possible to setup suitable port forwarding rules on the LAN interface. (I've never tried it.)
-
That sounds like a better explanation. It's not possible to 'arrive' on WAN from the inside?
The work around I used to use was just to add a local dns entry pointing to my web server in DMZ. That's fine but it doesn't allow you to test any port forwarding rules you may have set.
You have to phone a friend or, as I have resorted to in the past, use a dial-up connection to test! ::)Steve
-
OK, it seems that I cannot access my WAN address from my LAN to test port forwarding and such, I also cannot connect to any RDP sessions or my FTP server this way. All blocked with default deny.
A quick switch back to IPCop allows me to do all of this.
Now if I get my laptop online via my phone (It
s fooking slow >:() I can hit my FTP via my WAN but it still times out its so slow, I can also see the beginnings of an RDP session firing up but that times out too due to the speed of my phone connection (presumably).Now all of this works when I use IPCop (on my network, not thru phone, that gotta be less than dial-up! I kid you not). And all these attemps show up in PFSenses Firewall logs as blocked.
Hmmm, I`ve even removed all NAT/Rules and re-instated them and it still not working.
:'( :'( :'( :'(
-
OK, it seems that I cannot access my WAN address from my LAN to test port forwarding and such, I also cannot connect to any RDP sessions or my FTP server this way. All blocked with default deny.
Then you haven't setup your firewall rules correctly. Did you setup appropriate port forwarding on LAN? But is this of any real value anyway since you presumably want to test port forwarding from WAN, not port forwarding from LAN? If you provide more details (your relevant firewall log entries, LAN port forwarding rules, interface IP addresses, interface firewall rules) I'll be happy to take a look at them.
Hmmm, I`ve even removed all NAT/Rules and re-instated them and it still not working.
If you put the same rules back it will likely behave the same way.
Testing WAN port forwarding through the LAN interface runs the danger of reporting false positives. For example, if your internet link is down then (even with IPCop) the port forwarding through the LAN interface will likely work but no-one will be able to access your servers from the Internet. I suspect that if you knew enough about IPCop you could even imagine some other circumstances where IPCop might successfully port forward from the LAN interface but not from the Internet.
Now if I get my laptop online via my phone (It
s fooking slow >:() I can hit my FTP via my WAN but it still times out its so slow, I can also see the beginnings of an RDP session firing up but that times out too due to the speed of my phone connection (presumably).Sounds like your port forwarding rules are setup appropriately and you have a method of testing WAN interface port forwarding.
What services are you port forwarding? Telnet can be a useful test tool to connect to web server, smtp server (and probably others) which identify themselves and don't require much bandwidth. For example, telnet host 25 will connect to smtp server on host and host will identify itself; if you give command telnet host 80 and type HELO when telnet reports that it is connected you can generally get a response from the web server at host.
-
What's confusing here is that you seem to be reporting that it's working. All as expected.
The port forwarding you have setup is only supposed to do anything from outside your network. That's why I had to use dial-up to test it.
From inside the firewall, on LAN, you can just reach your servers directly via their local IP address. Or if you want to use a url or local name add entries to the hosts file (can you do that on pfSense?).What are you trying to do that isn't happening?
Steve
-
OK, here goes…. ;D
I cannot connect from my LAN to my WAN to test port forwarding and as has already been pointed out, I now know why this won`t work.
Now I also don
t have any device here at all with a good old dial-up modem installed, I have a landline, but no modem, I may find one if I rummage around but thatll just mean me having to bodge a system together with a modem in and most likely encounter innumerable amounts of other issues along the way (just the way it is for me I think).Also of all my friends/buddies/mates/aquaintances, there are a few I would trust, but they
re also a while behind me in the technical department, and Im far from "up there"!May have to walk someone thru it on the fone sometime.
Also, I don`t have any mail/web servers, only FTP.
All this and still, while it looks like an FTP session will connect, it doesn`t and the firewall log shows it as being blocked due to deny rule.
Likewise with the RDP, it looks like it
s gonna start, but it doesnt and firewall log shows it blocked due to deny rule (little red X`s).Now, If while using IPCop I try to FTP into my server using my laptop and phone, It`s slow, but it does get in and I can browse around it.
Still unable to RDP via my phone even with the settings turned right down.
A speedtest.net test via my phone indicates 650ms ping 0.06Mbps down and 0.04Mbps up now if my numbers are right that
s about 60Kbps down and 40Kbps up which is round about Dial-Up speed, God I dont remember dial-up being that slow when we had it.....Ah well, so much for playing with VPN`s eh!?! ;D
