Alright, I think I know what to do. Since the pfSense device isn't the DHCP server it needs an internal IP from my modem/router. Not exactly, on pfSense you setup the WAN interface to use DHCP to automatically get a WAN IP address from the modem. Because your modem is also a router, the address pfSense gets will be an "internal" RFC1918 address that cannot be routed on the Internet (192.168.x.x for eg.) You need to make sure the pfSense WAN interface is setup for DHCP on IPv4, None on IPv6 and uncheck the box that says "Block private networks and loopback addresses". Enabling DHCP on the LAN interface makes it so the rest of my devices can get their IP's from the modem/router and through the firewall (pfSense)? I do have a question about the upstream gateway… is that asking for the local IP of my modem/router? I entered that figuring that's what it meant but it didn't really seem to do much. Is that something that only gets configured for the WAN interface? pfSense does provide DHCP on its LAN interface (make sure to set it up that way). DHCP on the pfSense LAN interface is provided to all your attached devices so that they get an "internal" (RFC1918) address that matches the subnet defined for the LAN interface. They will ask pfSense to tell them how to get "out to the internet" (or anywhere other than their LAN subnet). The neat thing is they have no idea (nor do they need any) how pfSense does that, they don't know about the modem/router or the WAN IP They know the address/subnet pfSense gave them and that the pfSense LAN address is where they can go to get "outside". This why you DO NOT WANT to enter a gateway address anywhere, leave it at default and pfSense can make things work. Another subtle gotcha in this setup is that the pfSense LAN subnet CANNOT be the same as the subnet handed out by the modem/router. This goes back to my earlier advice to move off of the "default" RFC1918 addresses (192.168.0.x,192.168.1.x, etc) As always, the description of these setups is always WAAAAAY longer than actually doing them.

@shoaib2: what i doafter the installation of pfsense… You do know this is a firewall, don't you?

It is solved. The problem was the ISP device. It was just a coincidence, after the upgrade didn't worked. :)

Fixed. It helps when you have the wires plugged into the right holes  :-[

You can probably reinstall it from scratch with a stock version and be fine. Your config backup can be restored afterwards.

I'd hate to put it out there and something happens and for whatever reason I'm not able to fix quickly. That's why I suggested you keep a 2.0 install CD on hand. Without any package issues, there's really very little to hold you back. If you've got a recent config.xml backup (which you need anyway) then you've got (2) scenarios: The best case, you load 2.2.6 2.3 from scratch, reload the backup and you're good to go. The worst case, the 2.2.6 2.3 install goes pear shaped and you reinstall 2.0 from scratch, reload the backup and your back to where you started. The worst you get is back to where you are today, but at least you'll learn something about how the hardware responds to a 2.2.6 2.3 install. Edit Seeing as 2.3 is now RC (https://forum.pfsense.org/index.php?topic=109076.0) you're better off trying to get the advantages of the latest hardware fixes included w/ a current version of FreeBSD and the code improvements in pfSense 2.3 I've got $0.05 that says you'll have a smooth upgrade if you do a fresh install and restore your config.xml to 2.3  ;)

It'll keep the serial console enabled on the appropriate port, but yes if your config has a different baud it'll change the baud to that in your restored config. Change that under System>Advanced to 115200 and it'll stay that way. Don't change the loader files manually, they'll go back to your config file's setting eventually.

Without a DHCP server where? Yes, it works fine - some might say it works best - with static WAN IP addresses. A /29 is a nice start.

After changing the ip's as suggested and removing the "loop" everything started working like clock work :) thanks allot guys!

Fix the date/time on the pfSense firewall. Go to the console (video, serial, ssh, whatever). Start a shell. Run: pfSsh.php playback generateguicert That will generate and activate a fresh GUI cert for you automatically.

It is. For the first one, you'd have to push a route to the client for that particular website. You can even push it by dns name, but you have to set manually in the installed OpenVPN client's config the allow-pull-fqdn parameter. For the second one, it works out of the box. You'd create two OpenVPN server instances (running on two different ports) for the two types of users. Assign the created server's tun interfaces as pfSense network interfaces, and then you can apply firewall rules to them as usual (for the first one to only allow access through wan, and for the second one allow acess through the second nic lan). You'd have to set up hybrid NAT too, for the first one to access that special site from behind the VPN tunnel.

The 100baseTX will only be there if you set it there. The only possibility outside of explicitly setting it on that interface that I can think of is this issue where interface assignments with VLAN changes can end up shifting, in which case maybe a VLAN ended up changing assignment to another interface that had 100basetx set, but that doesn't sound like the case. https://redmine.pfsense.org/issues/3209 situation described in: https://redmine.pfsense.org/projects/pfsense/repository/revisions/1c32fb7e988fae89cf2da474778f39bcdd8a8656 Guessing it's more likely you're assigning a VLAN to an interface that had 100baseTX set.

If the mtu is 4 byte smaller it most likely has to do with the vlan128 you have on the wan. This will be the vlan tag:  Two bytes are used for the tag protocol identifier (TPID), the other two bytes for tag control information (TCI) So this indicates you will have a subinterface 128 on your wan, and the default gateway is .178. I would expect this at the provider side, but you wrote you hit the webinterface of the vigor at that address. The subnet you have with 255.255.255.248 mask has network address 178.x.y.176 and usable adresses are .177 to .182 Normally a default gateway woud be first usable address. (.177) Can you find a static route to 0.0.0.0/0 in the vigor pointing to 178.x.y.177 ? The ip addres the vigor gets via dhcp might only be for fiber to manage the device through.. What you could try with pfsense is to make the wan ip address .178 with subnet mask 255.255.255.248 (in the subinterface 128) You than would need to make aliasses for the public adresses on the wan side, and nat your internal ranges to these aliasses. So 192.168.1.0/24 to .181 192.168.2.0/24 to .180 192.168.3.0/24 to .179 See this: https://forum.pfsense.org/index.php/topic,64387.0/topicseen.html I think you not need that dhcp stuff at all, as the vigor is not longer used.

Oh okay then I will try. Thanks. I will keep you posted

@deajan: Hello, as you're using a CF card, you have a NanoBSD setup which won't be of great use if you intend to use Squid or any other disk space hungry plugins. The best advice I can think of is to make a clean install and restore the config file from the NanoBSD install, and then reinstall the packages. Yeah I decided to do that, moving files would most likely cause major issues in the future. Thank you!

Thanks for the advice, I know linux can't deal with GEOM and slices as in FreeBSD. The funny part is that CloneZilla is supposed to deal with FreeBSD partition scheme, but can't handle pfSense's one. Anyway, this was my quick and (really) dirty solution to handle my problem in a couple of hours.

@shaharhd: I followed this: https://www.netgate.com/docs/rcc-ve-2440/pfsense.html You're fine. The bits weren't technically all wiped from the drive, but your reinstalled OS can't read any of them that remain.