Re: [pfSense] Access to WebGUI from local net blocked, why?
It seems the web access is only blocked from one IP in the subnet, if I try to connect from another IP, it works. Trying to delete or show the blocked IPs with pfctl -t sshlockout -T delete ip doesn't help. I had too many failed login attempts through XMLRPC sync from the IP in question, since the user name given in the corresponding configuration field gets ignored and silently replaced by admin (this is probalby a bug, needs confirmation though). Is there another blocking mechanism involved somewhere? Regards, Adrian. On 01.12.14 01:21, Adrian Zaugg wrote: Hi there Probably I overlook something really simple, but I can't access the WebGUI on a certain lan interface. It perfectly works on other lan interfaces though. I have configured that interface with an any-to-any-all rule. If I'm in the same subnet, I am able to ping the box, to ssh into it, to connect to port 80, but not port 443. Testing from the box cli with openssl s_client -connect interface ip:443 presents me the certificate, doing the same from remote (in the same subnet), it doesn't connect and times out. Every time I try to connect 443 on that interface, I find a blocked entry in the firewall log. Shouldn't it pass? What's my mistake or misunderstanding? Thank you for your help! Regards, Adrian. ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Access to WebGUI from local net blocked, why?
You should provide the version number of the software. On Dec 1, 2014, at 7:03 AM, Adrian Zaugg a...@ente.limmat.ch wrote: It seems the web access is only blocked from one IP in the subnet, if I try to connect from another IP, it works. Trying to delete or show the blocked IPs with pfctl -t sshlockout -T delete ip doesn't help. I had too many failed login attempts through XMLRPC sync from the IP in question, since the user name given in the corresponding configuration field gets ignored and silently replaced by admin (this is probalby a bug, needs confirmation though). Is there another blocking mechanism involved somewhere? Regards, Adrian. On 01.12.14 01:21, Adrian Zaugg wrote: Hi there Probably I overlook something really simple, but I can't access the WebGUI on a certain lan interface. It perfectly works on other lan interfaces though. I have configured that interface with an any-to-any-all rule. If I'm in the same subnet, I am able to ping the box, to ssh into it, to connect to port 80, but not port 443. Testing from the box cli with openssl s_client -connect interface ip:443 presents me the certificate, doing the same from remote (in the same subnet), it doesn't connect and times out. Every time I try to connect 443 on that interface, I find a blocked entry in the firewall log. Shouldn't it pass? What's my mistake or misunderstanding? Thank you for your help! Regards, Adrian. ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Access to WebGUI from local net blocked, why?
pfsense 2.1.5-RELEASE (amd64), nanobsd 2G On 01.12.14 15:10, Ryan Coleman wrote: You should provide the version number of the software. On Dec 1, 2014, at 7:03 AM, Adrian Zaugg a...@ente.limmat.ch wrote: It seems the web access is only blocked from one IP in the subnet, if I try to connect from another IP, it works. Trying to delete or show the blocked IPs with pfctl -t sshlockout -T delete ip doesn't help. I had too many failed login attempts through XMLRPC sync from the IP in question, since the user name given in the corresponding configuration field gets ignored and silently replaced by admin (this is probalby a bug, needs confirmation though). Is there another blocking mechanism involved somewhere? Regards, Adrian. On 01.12.14 01:21, Adrian Zaugg wrote: Hi there Probably I overlook something really simple, but I can't access the WebGUI on a certain lan interface. It perfectly works on other lan interfaces though. I have configured that interface with an any-to-any-all rule. If I'm in the same subnet, I am able to ping the box, to ssh into it, to connect to port 80, but not port 443. Testing from the box cli with openssl s_client -connect interface ip:443 presents me the certificate, doing the same from remote (in the same subnet), it doesn't connect and times out. Every time I try to connect 443 on that interface, I find a blocked entry in the firewall log. Shouldn't it pass? What's my mistake or misunderstanding? Thank you for your help! Regards, Adrian. ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
[pfSense] OpenVPN Non-admin users.
I'd like to poll how others have dealt with the issue of non-admin Windows users running OpenVPN (TUN) for remote access. If you recall, non-admin users don't have the privileged of inserting a routes, so even though the tunnel is is established, it won't be used without an explicit route. I've read all of the scenarios, from running the client as a service, disabling username/password, creating client shortcuts with elevated privilege etc, using the Viscosity client for windows (only needs admin to be installed, not to be used). If you feel like showing off your astute reasoning, which route did you take and why? ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
[pfSense] OpenVPN Support Forum • Critical denial of service vulnerability in OpenVPN servers : Announcements
https://forums.openvpn.net/topic17625.html ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] [Bulk] OpenVPN Non-admin users.
-using the OpenVPNManager (there is a checkbox to include it in the installer in the openvpnexport package) Karl Fife schreef op 1-12-2014 21:37: I'd like to poll how others have dealt with the issue of non-admin Windows users running OpenVPN (TUN) for remote access. If you recall, non-admin users don't have the privileged of inserting a routes, so even though the tunnel is is established, it won't be used without an explicit route. I've read all of the scenarios, from running the client as a service, disabling username/password, creating client shortcuts with elevated privilege etc, using the Viscosity client for windows (only needs admin to be installed, not to be used). If you feel like showing off your astute reasoning, which route did you take and why? ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] OpenVPN Non-admin users.
We add them to the Windows built-in Network Configuration Operators group, and that gives them enough privilege to add routes, and we use the standard Openvpn client GUI. We need for our end users to be able to bring up/down the tunnel, and so auto-starting as a service proved not workable. Gordon Russell Clarke County IT 540 955 5135 - Original Message - From: Karl Fife karlf...@gmail.com To: ESF - Electric Sheep Fencing pfSense Support list@lists.pfsense.org Sent: Monday, December 1, 2014 3:37:25 PM Subject: [pfSense] OpenVPN Non-admin users. I'd like to poll how others have dealt with the issue of non-admin Windows users running OpenVPN (TUN) for remote access. If you recall, non-admin users don't have the privileged of inserting a routes, so even though the tunnel is is established, it won't be used without an explicit route. I've read all of the scenarios, from running the client as a service, disabling username/password, creating client shortcuts with elevated privilege etc, using the Viscosity client for windows (only needs admin to be installed, not to be used). If you feel like showing off your astute reasoning, which route did you take and why? ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] OpenVPN Non-admin users.
Am 01.12.2014 um 21:37 schrieb Karl Fife: I'd like to poll how others have dealt with the issue of non-admin Windows users running OpenVPN (TUN) for remote access. If you recall, non-admin users don't have the privileged of inserting a routes, so even though the tunnel is is established, it won't be used without an explicit route. http://openvpn-mi-gui.inside-security.de/ -Stefan ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] OpenVPN Non-admin users.
We add them to the Windows built-in Network Configuration Operators Do you know this to work with Windows 8 Enterprise (or Win 10 for that matter)? I've seen this work in some versions of Windows, but when we tried it in Win 8 Enterprise, it didn't seem to work. We didn't probe further, suspecting that it was due to security changes in Windows =8. On 12/1/2014 3:04 PM, Gordon Russell wrote: We add them to the Windows built-in Network Configuration Operators group, and that gives them enough privilege to add routes, and we use the standard Openvpn client GUI. We need for our end users to be able to bring up/down the tunnel, and so auto-starting as a service proved not workable. Gordon Russell Clarke County IT 540 955 5135 - Original Message - From: Karl Fife karlf...@gmail.com To: ESF - Electric Sheep Fencing pfSense Support list@lists.pfsense.org Sent: Monday, December 1, 2014 3:37:25 PM Subject: [pfSense] OpenVPN Non-admin users. I'd like to poll how others have dealt with the issue of non-admin Windows users running OpenVPN (TUN) for remote access. If you recall, non-admin users don't have the privileged of inserting a routes, so even though the tunnel is is established, it won't be used without an explicit route. I've read all of the scenarios, from running the client as a service, disabling username/password, creating client shortcuts with elevated privilege etc, using the Viscosity client for windows (only needs admin to be installed, not to be used). If you feel like showing off your astute reasoning, which route did you take and why? ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
