PFSense implementation help…

BigBadAl

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 ;)

stephenw10

@BigBadAl:

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

wallabybob

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)

BigBadAl

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 0

Any ideas?

Thanks</link#8></link#7></link#6></link#5></link#4></link#3></link#2></link#1>

wallabybob

@BigBadAl:

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.

@BigBadAl:

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

@BigBadAl:

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.

@BigBadAl:

netstat -i gives me

No significant errors counted on any interfaces, all interfaces receiving so probably no cable problems.

@BigBadAl:

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

BigBadAl

Ah sorry, thatl teach me to jump in size 12s 1st…

Netstat -r -n gives...

$ netstat -r -n
Routing tables

Internet:
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 lo0

Internet6:
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 lo0

heres 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 UDP

and my interfaces are....

WAN interface (fxp0)
LAN interface (re0)
DMZ interface (re1)

My DMZ (re1) is not connected at the moment

wallabybob

There are some strange things you have reported:

@BigBadAl:

$ netstat -r -n
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.1 UGS 0 2 fxp0

Your default gateway has a private IP address on your LAN subnet and is accessed through your WAN interface? How is that going to work?

@BigBadAl:

heres 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 UDP

What is this BRIDGE0 interface? It doesn't show up in anything you have previously provided.

BigBadAl

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

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

BigBadAl

OK, while Ive 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 its a 433Mhz… think its a celeron too! I give in!

So up to now Im good (well lets say better shall we ;))

No doubt therell be many more daft questions over the coming weeks, most notably when I replace my LAN and DMZ nics for Intel pro 1000 MTs

So to WallabyBob, many thanks for all your assistance and to all who assisted, I thank you and Goodnight!

wallabybob

@BigBadAl:

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.

@BigBadAl:

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.

BigBadAl

Well, that`s certainly an odd one….

My PFSense is now on the LAN with its 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

stephenw10

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

BigBadAl

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…

BigBadAl

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

stephenw10

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

BigBadAl

Ive 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 5678

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

stephenw10

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

BigBadAl

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.

stephenw10

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

wallabybob

@stephenw10:

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