The question for me is... is your diagram just a quick mockup to give us an idea of what you want to do or is everything already physically connected that way? A high-level, straight forward approach for accomplishing your goals would be: Create VLANs on the PFsense LAN interface Consolidate down to 1 managed switch and connect it to PFsense via a trunked interface Connect everything to the managed switch Configure firewall rules to control access as necessary There's no way to accomplish everything you're looking for as currently shown in your diagram. If you keep the transit network, you can establish connectivity by moving your servers to one of the other switches, but that would mean your VLANs would be terminated on the middle L3 switch and you'd lose inter-vlan firewalling capability. This would be the favorable design from a performance standpoint, but you lose granularity in your access control. If you want to keep the 3 switches and require inter-vlan firewalling, you can still accomplish your goals, but it would require a re-design and managed switches. You'd need to: Create VLANs on the PFsense LAN interface Re-configure the link between PFsense and the middle switch as a trunk Trunk the two outside switches to the middle switch Move your servers to any of the three switches If everything is in close proximity, personally I would consolidate down to one managed switch to keep it simple. Regardless of your design choice, in order to fulfill all of your requirements, all roads lead to managed switches and a re-design.

Everything depends on your setup. Would need more details. Post a network map. Are your VLANs terminated on PFsense or your switch? Post your server1.conf What are the IP's in the VLAN you're trying to access? What do the rules look like on your LAN and OpenVPN tab?

Like an i3-8100t? Then yes. Easily. Steve

Mmm, I agree it seems odd. Have you been able to test it in FreeBSD directly? If it is something we are doing in pfSense we could dig into it but if it's something FreeBSD does it would need to be reported upstream really. Steve

Now if only I could edit the topic, I could change it to solved!

teşekkür ederim ilginiz için

@k15 Don't mention it Good luck

Create a LAGG on pfsense and on the switch stack. Use the LAGG as the vlan parent.

@derelict I say that's a constant regardless of what you do :)

@grimson Thanks, I do read manual but in this case I don't know where to start so I asked question here and yes I only have 1 physical line (at-least for now), I will add quad gigabit ethernet nic to my PC next month.

@stephenw10 Muito obrigado pelas informações... Irei realizar a troca do HD e cabo sata e atualizar o servidor para a versão 2.4.4... Grande Abraço!!!!!!!

I assume this was resolved in the other thread? Steve

Get it in where?? Not sure why you think you need a WAN IP to resolve to something in your arp table for vpn clients to connect to you? I am thinking you still don't quite grasp what a PTR or reverse is... Your vpn.domain.tld resolves to IP.242 address.

modem reboot solved the problem thankyou very much for your help!! this is the traceroute from inside the firewall. 0_1540757854627_Traceroute from inside after modem reboot Document.txt

Mmm, I would think there are better ways to do this. But if you wanted to do it like this you will need to setup an OpenVPN tunnel between the two sites to route traffic across, you can't route over IPSec for this. You will need the OpenVPN interfaces assigned at least at the UK end to get reply-to states on traffic coming across the tunnel. Then: Move the VMs to the 192.168.20.0/24 subnet in the UK. That may well be non-trivial! Change your port forwards in the US firewall to point to the new internal IPs. Add policy routing rules on the UK firewall to route traffic from those VM out via the US if that is required for traffic initiated by the VMs. Add outbound NAT rules on the US side for the 20.0/24 subnet to allo that traffic out. Steve

Hi Mate. Thanks for your response. I don't think so , the wan is set up statically and supplied by a data centre. The connection will be coming from another firewall VLAN. When we plugged the older pfsense in with the same config no issues were occurring. Just trying to look through the logs using shell due to the fact they only show a certain time in the GUI. Thanks

Yes. Just like you would with an rfc1918 network. If they routed 1.1.1.0/25 to you: Interface: 1.1.1.1 /25 Usable: 1.1.1.2 - 1.1.1.126 They'd set 1.1.1.1 as the gateway. Or you could configure DHCP to hand out the addresses if you wanted. You could also just use a /26, /27, /28, /29, /30, /31 on the inside interface and use the rest of the space for other purposes.

I hadd some details and examples : @free4 said in PFsense 2.4.4 FreeRadius Mac Address Authentication Qouta: "Reauthenticate users" must be enabled on the captive portal Normal. A the doc states - or the video. Radius accounting must be enabled (using "stop/start (Freeradius)" ) on the captive portal Or "Interim", which I use, and work s fine. Radius accounting must be also enabled on the FreeRadius package (in the "Interface" tab) Yep. I've these (maybe over complete, but it works so good this way) : A cron must be set up using the cron package to reset the daily counters Correct. Here it is : The first 3 lines : the daily/weekly/monthly/ reset. Choose your hour of reset. Line 4 : private mixture, (192.168.2.1 is my NAS) to delete the overwhelming logs of FreeRadius - if you forget this one, and ask FreeRdius to log, and forget about it, then your pfSense will explode ... Btw : test this line by hand before you unleash a wild "rm" on your system. Have a look at /var/log/radacct/datacounter/daily/ - see the files yourself. That makes undderstanding things much faster. Use the FreeRadius config files, these scripts here : /usr/local/etc/raddb/scripts ... and then you know how the guy works, which is great if you want to debug something (add some log lines).

If you just want to do DNS bases blacklisting you could take a look at pfBlockerNG.

Die Anzeige der Rufnummer ist von Anbieter zu Anbieter unterschiedlich und wird in der Fritzbox korrigiert, wenn du dort auch Telekom hinterlegst. Bei "anderm Anbieter" passiert das nicht bzw. du mußt das manuell machen. im ip-phone-forum ist da einiges zu finden. Gruß pfadmin

Merci @ccnet pour votre retour. Alors depuis mon espace OVH je vois bien une passerelle mais sur mon VPS, il n'y a aucune passerelle de configurer... 2001:41d0:0305:2100:0000:0000:0000:0001 Effectivement le but de ma démarche et d'obtenir une passerelle afin d'interconnecté mon VPS avec un réseau exterieur.

@thehermit Hardware encryption will probably be a requirement for v 2.5

@jimp Thank you! It worked.

Whatever the proxy is for or is doing is probably messing up DNS resolution for your pfSense. The package management system needs a completely clean DNS resolution to operate properly, namely there can not be any filtering or tampering with SRV records, the pkg package manager uses those all the time for finding suitable mirrors for the packages. Either that or the proxy is doing something to the http(s) downloads of the package catalogs to mess up the update system.

@medikopter said in OpenVPN TLS Fehler: Das klingt ja eigentlich ganz cool und simple, allerdings scheitere ich schon an der Umsetzung eines Failover. Nunja, aber das sind ja auch zwei verschiedene paar Stiefel ;) VPN auf beiden Interfaces zum Laufen zu bringen ist wesentlich leichter, weil du nichts umschalten/routen/sonstwas musst. Daher überhaupt nicht schwer. Also das er das Interface automatisch wechselt wenn eins Down ist. Es genügt doch eine Gateway Gruppe zu machen und die bei den Regeln auf dem LAN einzusetzen?

@andyc Yeah, i want to have access to my ESXi management from work and at home. (only for a while, as I am preparing everything for my VM ect ..) i will make a IP restriction or something like that if it's possible, to allow only my home public IP and the work IP Or i can just do a VPN with my pfSense (i saw come options to do this), i don't know, i'll think about it