Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - minitux

#1
Hi Amr,

yes, I do think its a routing problem. Option 1 is a no goer as I want to centralise both on the same machine. Option 2 is what I think i need but what I don't understand is how I tell Squid to route traffic through the VPN. I understand how Squid listens on localhost:3128 for incoming traffic from the LAN (Squid is bound to the LAN interface) but what I don't understand is how it routes outward traffic. Is it a forward routing from localhost:3128 -> VPN_WAN interface?
At the moment I have forwarding rules (Firewall->NAT->Outbound) that go from the LAN to the VPN_WAN. Squid seems to have short-circuited the forward routing process whereby it doesn't see the VPN_WAN interfaces but goes straight to the WAN interface.
#2
Hi,

I have 2.4.5-RELEASE-p1 (amd64) device to which my LAN directs all traffic. OS routes all traffic via OpenVPN and works great without leaking any IP (Using unbound). I used this guide https://nguvu.org/pfsense/pfsense-multi-vpn-wan/ to set it up.

I've spent the entire night configuring Squid/Squidguard and not I find that Squid is leaking my IP as if completely ignoring OpenVPN. I have outbound NAT configured so that all LAN traffic is bound to VPN_WAN address but with Squid in operation these seem to be ignore, as if Squid took precedence over everything else.

Any suggestions on how I can stop Squid leaking my IP?

Thanks

#3
Hi,

I have a couple of VLANs set. One of these, on the 192.168.40.1 subnet, is assigned to my Sky Q set top box. This subnet is assigned a "guest" behaviour so it cannot communicate with other subnets but it can go on the internet. Downstream of opensense is a cisco sg300 VLAN capable switch. The Sky Q is plugged into port 4.

The i have a few temperature sensors that log in via wireless over another subnet 192.168.1.1. DHCP server assigns static IP (on the subnet 192.168.1.1) base on mac address to these sensors. When the Sky Q is plugged in, the DHCP server assigns incorrect IP from the 192.168.40.1 subnet instead of the 192.168.1.1 subnet. See below.

Dec 15 02:17:45   dhcpd      DHCPACK on 192.168.1.61 to 60:01:xx:xx:xx:xx via em2
Dec 15 02:17:45   dhcpd      DHCPREQUEST for 192.168.1.61 (192.168.1.1) from 60:01:xx:xx:xx:xx via em2
Dec 15 02:17:45   dhcpd      DHCPOFFER on 192.168.1.61 to 60:01:xx:xx:xx:xx via em2
Dec 15 02:07:36   dhcpd      DHCPNAK on 192.168.1.61 to 60:01:xx:xx:xx:xx via em3.40
Dec 15 02:07:36   dhcpd      DHCPREQUEST for 192.168.1.61 (192.168.1.1) from 60:01:xx:xx:xx:xx via em3.40: wrong network.
Dec 15 02:07:36   dhcpd      DHCPACK on 192.168.1.61 to 60:01:xx:xx:xx:xx via em2
Dec 15 02:07:36   dhcpd      DHCPREQUEST for 192.168.1.61 (192.168.1.1) from 60:01:xx:xx:xx:xx via em2

is it as if the SkyQ was acting as an access point as its the only wireless unit active on the em3.40 subnet. Is this possible? Do you not find this strange?

Cheers
#4
General Discussion / Re: Google ... why Google ...?
February 03, 2019, 11:38:56 PM
Thanks folks for your replies. I was thinking about Nextcloud when I wrote the post ... :-)

And I need to learn more about the Google Authenticator. I always thought it linked to Google servers ...
#5
General Discussion / Google ... why Google ...?
February 02, 2019, 01:19:03 AM
Hi,

just bumped into OpenSense while browsing Diaspora*. Looks good. As a long time user of pfSense, it would be good to understand what brought about the fork from pfSense? I find the forum on pfSense quite dormant while there appears to be quite a bit of traffic here, which suggests a wider user base.

What I am not liking is the widespread use of the Google word. "Save config on Google Drive" ... "two factor authentication with Google" all stuff that makes me shiver ... why this choice to go down the route of having to rely on the bigger spying machine on the planet .. had in hand with Facebook I guess ...?