[pfSense Support] strange routing behaviour with static routes, packet leak? at least packet lost.
Scenario /--cust vlan--\ | | B B Custrsat A--vlan FW2SAT---PFsense---vlan FW2Inet---A rinet Specific static routes defined in the pfsense to reach some remote sites throught rsat router over the vlan FW2SAT. Route 0/0 is configured in the pfsense to forward all the traffic over rinet. Rsat A and Rsat B are different interfaces of the same router Rinet A as well Rinet B are different interfaces of the same router Ok, this is working ok so far as we were able to see with MTR. lds quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 10.52.18.2010.0%140.2 0.9 0.1 10.4 2.7 pfsense1 2. 10.53.0.65 0.0%140.5 0.4 0.4 0.6 0.1 rsat A 3. 10.139.4.1 0.0%13 567.0 609.1 550.0 676.3 40.1 Customer The hops are ok But some times, after a while, without any explanation, change in the network or dynamic routing protocol or similar the pfsense looks like it is forwarding the traffic over rinet (A side), making this path: Packets Pings HostLoss% Snt Last Avg Best Wrst StDev 1. 10.52.18.201 0.0% 527340.3 0.1 0.1 27.50.6 pfsense1 2. 10.53.0.65 0.0% 527331.0 0.3 0.3 100.0 2.6 rsat A 88.xx.yyy.195 rinet B 3. 10.139.4.1 0.0% 52733 605.9 741.2 0.4 2799. 276.6 customer 10.51.2.57 rsat B This last behaviour is totally unexpected and incorrect in our network and I can find any explanation for it. It also generates a non symetric path because the TX from the pc behind pfsense1 is going thought the incorrect path and the RX (from customer to the pc) is coming back directly throught rsat B :-/ So far it is not having impact in the customer service but our nms is becoming crazy sometimes because this new path -which works for a very few packets- is not a proper way and it generates a packet lost and alarms. PFsense version is 1.2.2 with several vlans. Dynamic routing over cust vlan is stable. We don't consider switching layer as 3750 stacks -were the pfsenses are connected- a problem yet. Any idea comment or suggestion? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Firewall drops all packets after upgrade from 1.2 to 1.2.3
Am 30.03.2010 19:23, schrieb Chris Buechler: [...] Then just go to System Advanced and check Bypass firewall rules for traffic on the same interface. This option was already checked. Nothing changes if I uncheck the option. Do you have any other idea? Regards Bastian - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Firewall drops all packets after upgrade from 1.2 to 1.2.3
On 30/03/10 17:06, Bastian Schern wrote: Do you have an idea how to find out were the problem with asymmetric routing is? traceroute from each endpoint to the other and use tcpdump on firewalls to observe if the packets go where you expect them? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] pfsense reset
Hiya I need would like to reset my pfsense to the factory default settings. How would one setup pfsense via command line to enable access the webgui. Kind Regards Brent Clark - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] pfsense reset
Brent Clark wrote: Hiya I need would like to reset my pfsense to the factory default settings. How would one setup pfsense via command line to enable access the webgui. Kind Regards Brent Clark Connect console or ssh to your pfSense and choose option 4) pfSense console setup *** 0) Logout (SSH only) 1) Assign Interfaces 2) Set LAN IP address 3) Reset webConfigurator password 4) Reset to factory defaults 5) Reboot system 6) Halt system 7) Ping host 8) Shell 9) PFtop 10) Filter Logs 11) Restart webConfigurator 12) pfSense Developer Shell 13) Upgrade from console 14) Disable Secure Shell (sshd) Enter an option: - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] VPN LAN TO LAN
OK, i've Enable HTTPS(443) on the WAN interface of my pfsense box; then how could I access my box remotely through internet is it https://ip address:443 Correct me if i'm wrong as looks like i could not access my box using https(443) what went wrong that i could not access by pfsense box. Joseph. On Sat, Mar 27, 2010 at 5:18 AM, Tim Dickson tdick...@aubergeresorts.comwrote: -- any hint on how to apply https over the INTERNET to my PFSENSE box ??? Enable HTTPS (443) on the WAN interface in your ruleset. -- and how could i access my LAN (clients PC) You were correct with VPN being the best way. You could put port forwards in as well, and you could also enable SSH and use tunneling. Totally depends on your needs - I'd check out OpenVPN. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] PPTP Connected?
- Original Message - From: Chris Buechler cbuech...@gmail.com To: support@pfsense.com Sent: Tuesday, March 30, 2010 10:41 PM Subject: Re: [pfSense Support] PPTP Connected? On Tue, Mar 30, 2010 at 5:39 AM, Tortise tort...@paradise.net.nz wrote: Hi Using 1.2.3-RELEASE (embedded) I have a PPTP server configured and I can connect remotely however I still cannot connect with anything on the LAN. I think the issue is the IP assigned to remote connections is remotely said to be 255.255.255.255 while the LAN is using 255.255.255.0, the IP address assigned seems OK. That's normal. You're probably missing a firewall rule on the PPTP tab. With a bit of list help it seems not so much a missing rule, but rather a rule that was too tight. The rule says Hint: in most cases, you should specify TCP here. It seems somewhat more than the TCP rule is required in my case. I'll do some more testing to clarify which is required, however * works well of course! If anyone wants to know more of what I find works then let me know. Btw it makes me wonder if the rules tightened up in a recent version here, as this used to work with the TCP rule on its own in the past? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
