PFSense implementation help…
-
Hi all, I`m new! ;D
Decided to give PFSense a go to replace my current IPCop box but ran into some problems…..
OK, I have PFSense installed on a PIII 866 with 512MB and 20GB with Red, Green and Orange.
Now if I connect this to my current setup I can access it thru it`s configured LAN IP, I had a play and thought "OK good stuff, time to try this out properly"
I installed this box in place of my current IPCop box: Red to CM, Green to LAN and Orange to DMZ.
Rebooted my CM and watched PFSense pick an IP Address up from my ISP via DHCP. all seemed well.
Now with it all set up this way, I can still access the box via it`s LAN IP but no internet access or DMZ access.
More reboots followed and still no access to web or DMZ. DHCP works fine on LAN and in the rules part I have a rule to pass all from LAN to ANY. I`ve even removed the rule and reinstated it and still no go. No web pages load no pings/tracerts get out.
So, I
m lost. I just cant see what or where the problem is, It`s gotta be something simple, that much I do know, but what or where, I dunno.Please help
Thanks
-
Which version? What settings were made for pfsense?
-
A number of people have reported that some cable modems are fussy about the MAC address of the downstream system. If the downstream system MAC address changes the cable modem modem needs to be cold restarted (power turned off for at least long enough for the power supply capacitors to drain; maybe at least 20 seconds; then powered on again.) I don't know if getting an IP address from the modem means the MAC address of the downstream system has been accepted.
There is a bunch of potential problems. What IP address and mask have been assigned to the WAN interface? What IP address and mask did you specify for the LAN interface?
-
Ah, erm… the version is the latest one (I think, I`ll get back to you on that one)
WAN IP Address: don
t know, cant remember I`ve reverted back to my IPCop now.The CM and MAC issue I think is not applicable here, as if I change the downstream device I`ll just get another IP, the only real restriction is that my ISP account is only allowed one IP to one MAC at a time. I can swap and change them around as much as I like, but I am allowed only one at a time.
PFSense box and CM were bounced several times and CM was off completely for a few minutes as I found a dodgy RJ45 on the end of a cable, re-terminated and tested ok between LAN switch and laptop.
LAN info: 192.168.1.x/24
WAN info: as above, don`t know
CM: Scientific Atlanta WebSTAR EPC2100R2
Service: 20/2
Switch: Procurve 1810G-24Thanks
-
CM: Scientific Atlanta WebSTAR EPC2100R2
These modems do NOT allow you to use multiple IP or MAC addresses. After the first MAC address is used it will not respond to further MAC addresses instead it gives them a 192.168.100.1 address.
You need to pull the power including the backup battery from the device for 30 seconds and then try pfsense again.
-
CM: Scientific Atlanta WebSTAR EPC2100R2
These modems do NOT allow you to use multiple IP or MAC addresses. After the first MAC address is used it will not respond to further MAC addresses instead it gives them a 192.168.100.1 address.
You need to pull the power including the backup battery from the device for 30 seconds and then try pfsense again.
I beg to differ notladstyle, having done it many times in the past and having done it again 20 secs after reading your post I am now posting from an entirely different IP address with my PC connected directly to my CM.
I can assure you that I can swap and change as much as I like, and that I will get a different IP address for each MAC I connect to my CM. These IP`s are leased for 24 hours so if at any point I reconnect a MAC I have used in the last 24 hours I will get that same IP that was issued to that MAC when it was first connected… that is how I know that when I reconnect back thru my IPCop box I will get the IP that was Assigned to IPCops red MAC.
Oh, and I used to work for the ISP in question, Virgin Media.
The 192.168.100.1 is the address used to connect to the CM`s webgui for diagnostics and signal levels and such, it cannot give that address out.
I am now going to reconnect back thru my IPCop (and get my 'normal' IP address back).
Don`t know if you can see the addresses that have been used for posting on the PFSense forums!?
-
In fact, now I`m back on my 'normal' address, I can see that all my original posts have my address showing to me and that last post is a different address.
I cannot however see any of your addresses, they`re showing up as logged which is how I assume mine are showing to you all.
Many thanks
Edit: I see that moderators can see my IP address used for each post, if one could pop in and confirm, that`d be great ;)
-
Oh, and I used to work for the ISP in question, Virgin Media.
Hard to argue with that! (Unless you were handing out leaflets in the high street! :P)
A strange case though. I too have come from IPCop and had no trouble replacing it with pfSense.
Steve
-
This question is still unanswered:
@dvserg:Which version? What settings were made for pfsense?
Time for a bit more high powered troubleshooting:
Any packets from WAN logged in the firewall log?
What is the state of each interface? (pfSense command # ifconfig -a)
What are the interface counters? (pfSense command # netstat -i)
What is the pfSense routing table? (pfSense command # netstat -rn)
-
OK,
PFSense version is: 1.2.3-RELEASE built on Sun Dec 6 23:38:21 EST 2009
Sorry, what settings are you referring to when you say What settings were made for pfsense?
Wan packets, is that status>system logs>firewall? if so in there I have a whole load of stuff with red X`s next to them…
if I click on the red X`s I get a pop up OK box saying " The rule that triggered this action is:
@110 block drop in log quick all label "Default deny rule""
Default deny rule.. that sounds like the problem....?
ipconfig -a gives me nothing at all
netstat -i gives me
$ netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
fxp0 1500 <link#1> 00:50:8b:d9:b9:46 91 0 424 0 0
fxp0 1500 fe80:1::250:8 fe80:1::250:8bff: 0 - 2 - -
fxp0 1500 77.101.88.0 cpc8-live20-2-0-c 72 - 71 - -
re0 1500 <link#2> 00:14:78:7e:cc:d5 710 0 655 0 0
re0 1500 fe80:2::214:7 fe80:2::214:78ff: 0 - 1 - -
re0 1500 192.168.1.0 pfsense 384 - 513 - -
re1 1500 <link#3> 00:0a:eb:2f:ed:6f 0 0 27 0 0
re1 1500 192.168.2.0 192.168.2.31 0 - 25 - -
re1 1500 fe80:3::20a:e fe80:3::20a:ebff: 0 - 0 - -
lo0 16384 <link#4> 0 0 0 0 0
lo0 16384 your-net localhost 0 - 0 - -netstat -m gives me
$ netstat -m
710/190/900 mbufs in use (current/cache/total)
708/66/774/4672 mbuf clusters in use (current/cache/total/max)
706/62 mbuf+clusters out of packet secondary zone in use (current/cache)
0/14/14/2336 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/1168 9k jumbo clusters in use (current/cache/total/max)
0/0/0/584 16k jumbo clusters in use (current/cache/total/max)
1593K/235K/1829K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/1424 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines
lo0 16384 ::1 ::1 0 - 0 - -
lo0 16384 fe80:4::1 fe80:4::1 0 - 0 - -
enc0* 1536 <link#5> 0 0 0 0 0
pfsyn 1460 <link#6> 0 0 0 0 0
pflog 33204 <link#7> 0 0 55 0 0
bridg 1500 <link#8> 32:a9:22:20:b3:09 352 0 814 0 0Any ideas?
Thanks</link#8></link#7></link#6></link#5></link#4></link#3></link#2></link#1>
-
Wan packets, is that status>system logs>firewall?
Yes, thats the path to the firewall log. I was interested if you have packets from the WAN interface logged there and you do so the WAN interface is up.
Default deny rule.. that sounds like the problem….?
Maybe a problem, depends of the addresses logged. I believe cable modems connect to a shared medium so stations can see traffic that isn't their's. So what you are seeing in the firewall log from the WAN interface could be just "noise".
ipconfig -a gives me nothing at all
Should have been ifconfig not ipconfig but no matter, other output has provided what I was looking for.
netstat -i gives me
No significant errors counted on any interfaces, all interfaces receiving so probably no cable problems.
netstat -m gives me
Ah, sorry I typed lower case version of NETSTAT -RN which unfortunately looks like lower case of NETSTAT -M
Please provide output of # netstat -r -n and a sample of the WAN interface entries from the firewall log and the interface usage (e.g. re0 is WAN, re1 is LAN and fxp0 is DMZ).
-
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
-
60K? I can still remember using my phone for dial up access at 9600bps! :o
I once tried to play counter-strike over it, some what laggy!Anyway now we're getting somewhere.
Just a thought, have you put in a default allow rule for your dmz interface?
Your ftp server will require that to open a return connection.For ftp what ports have you forwarded? Are you using active or passive?
Steve
-
Erm, as far as I know, I have not assigned any default allow rules, aside from not knowing exactly how to do that, would I set that for packets 'arriving' on the WAN interface or do I apply that to the DMZ for stuff going back out?
I
ve also switched back to IPCop for the time being, and I dont know whether this is in my head or not, but I`m sure regular browsing is quicker thru IPCop than thru PFSense!?!? I dunno!I also get 21.86Mb down and 1.83Mb up with IPCop and 18.34Mb down and 1.83Mb up with PFSense… Maybe that`s the 733Mhz of IPCop vesus the 433Mhz of PFSense!?!?
Could be the time of day, or just a fluke but that`s all beside the point, How do I go about this default allow rule for the DMZ?
Many thanks again
-
If you look at the firewall rules for lan you'll see that, by default, there is a rule that allows all traffic out to any destination.
In pfSense, and I think this differs from IPCop, when you add another interface you have to add a similar manually if you want to allow traffic out. By default everything is blocked. If you haven't added this rule then your servers in DMZ won't be able to send anything to WAN or LAN except in response to packets sent to them.I'm pretty sure this could break ftp.
Steve
-
If that works you'll probably want to then change your firewall rule as you'll then have it setup to allow access from DMZ to LAN, probably not something you want.
For example I have attched my rules on my wifi interface.
I want to allow wireless clients access to internet. To do that I allow access the local dns forwarder. I also allow access to the pfSense gui for my convenience. My last rule allows access to anywhere except the IP alias LOCAL which is 192.168...
Pretty much everything I have taked about earlier in this thread is more eloquently explained here.
Steve
