@KaSper(S)ky:

The first picture was the ip address 192.168.4.1, and later I changed to the 192.168.4.2.

Later changed what to 192.168.4.2? Clearly you changed the IP address you told the browser but did you also change the IP address of the pfSense LAN interface?

And why did you change what you changed?

On the information you have supplied I'm left believing you have your pfSense LAN interface with IP address 192.168.4.1 and you are attempting to access the pfSense web interface by accessing IP address 192.168.4.2 and complaining you can't access it. If you can't see what is wrong with that combination then you are out of your depth and probably need to get help from someone who can sit beside you and watch what you are doing and challenge you immediately you do something "unusual".

Maybe you just "forgot" to say you had also changed the pfSense LAN interface IP address to 192.168.4.2. If you repeatedly give me incorrect information or "forget" to tell me you just made a change or a few changes to my suggestions then I'm likely to feel my time would be better spent working with someone who provides accurate configuration data and closely follows my suggestions and tells when they do something different and why they did something different.

@KaSper(S)ky:

I dont set up default getway because I dont know which ip address should be standing there.

I hope you know now what the default gateway IP address should be.

@KaSper(S)ky:

Version 1.2.3 works fine while 2.0.1 is not. That's why I asked for help with the setup version 1.2.3.

I would be very happy to step aside if another reader wants to help you with pfSense 1.2.3. I'm not prepared to give you any assistance with pfSense 1.2.3.

"Doctor it huts when I do this!"
"Don't do that!"

As marcelloc said, snort is probably filling it up some way. Could be logs, or rules, or who knows what. snort is a large package. Trying to make that, and all its data, fit in a 512MB slice along with the base install of pfSense is probably not going to work out very well.

Grab a 4GB CF. They're cheap, buy a couple spares.

Requested details

WAN Modem IP (192.168.2.1)

OPT1 Modem IP (10.2.2.1)

WAN IP Address(192.168.2.2/24) , Gateway (192.168.2.1/24)

OPT1 IP Address (10.2.2.2/24), Gateway (10.2.2.1/24)

System-Gateway-Groups.JPG
System-Gateway-Groups.JPG_thumb
System-GW.JPG
System-GW.JPG_thumb

If all of the hostnames for that domain can be resolved by an IP across the tunnel, setup a DNS Forwarder Domain Override to point queries for the remote site's domain name to the DNS server on the other end. Should be that easy.

Looks like lighttpd 1.4.31 is working fine in the 2.0.2 and 2.1 snapshots, so this should be resolved unless someone else finds a problem with it.

@NumLock:

I have to make rules to vLan100 to get internet on vLan100?

Yes.

Go to: "System" –> "Routing" and Change the "Monitor IP" of one of your Gateways

What are your LAN firewall rules (please provide a screenshot)?

What are your port forwarding rules?

Can the Elastix (which I see is basically Asterix with extras) server connect to the Internet?

OK, thanks for that, will just have to change a few static ip assignments when I go "live" on the pfsense using PPPOE to WAN and bypassing the old router

Guessing the 109.190.0.52 is your IP from that example, at least judging by the fact the bandwidth is downstream. Something is doing ANY lookups on ripe.net and isc.org, which generate very large responses, at an absurd pace. Nothing on a stock pfSense install will generate any queries even remotely like that. Switch the capture to LAN and see if you see the requests there. In a default configuration, the only way any queries like that could possibly be initiated would be by something on an internal network.

In 2.1 it will also send a notification when a dyndns host changes, and if you have smtp notifications enabled, it will result in an e-mail sent to you when it updates the dyndns hostname.

DynDNS is definitely the way to go for that, then just use the hostname and you really don't need to care what the IP is.

You are clearly more familiar with this than me!  ;)

Personally I would be using this only for logging pfSense.
In the embedded install of pfSense the /var is a ram drive that's lost when you reboot. Clearly unsuitable for longterm logging. But as long as this is user selectable it's probably safer to force people to make a decision rather than potentially causing damage to solid state storage.

Steve

That is possible. It's no different from configuring one, just do it twice.

To preface this, I have been doing networking a LONG time, and actually know it quite well.

To answer your question, I need a lot more information about what you are trying to divide, and from how many people.  As an example, Vlan vs discreet nics;  A vlan can be busted out of and you can see all traffic, as well as load on one is (to some extent) load on all.  But you can not do trunk ports on discreet nics…

@AudiAddict:

Any idea's on how to resolve this?

Do a firmware upgrade to a snapshot build of pfSense 2.1 which is based on FreeBSD 8.3, one of the current versions. If you still have problems submit a FreeBSD problem report including the pfSense crash report.

I suspect it will be difficult to persuade any of the FreeBSD maintainers to look at problems in FreeBSD 8.1 (used in pfSense 2.0.1).

If you need help with any of that ask here.

I agree they are nice units.