Hi all,
on 5.2 I configured suid.conf to accept traffic from my remote VPN subnets using the following:
I have now come to do this on 6.4, and have found that the squid.conf no longer exists in the same format.
The parsed files such as squid_lans.conf state that they are automatically created from the network configuration, so I assume that I don't want to add lines in here.
Pete Baldwin references adding an extra lan (You can add extra networks in /etc/clearos/network.conf) in the 6.x feature tracker (http://tracker.clearfoundation.com/print_bug_page.php?bug_id=96), however I don't know if this is the right place to add them, as the IPSEC vpn app has must have already added the routes to the routing table (you can ping the remote device, juts no http access).
Has anyone configured remote subnet access in squid on 6.4? Please could you suggest which file I should be adding the VPN subnets.
Thanks
David
on 5.2 I configured suid.conf to accept traffic from my remote VPN subnets using the following:
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
# Example rule allowing access from your local networks. Adapt
# to list your (internal) IP networks from where browsing should
# be allowed
#acl our_networks src 192.168.1.0/24 192.168.2.0/24
#http_access allow our_networks
# dcc mod 8th August 2012
acl a1 src 10.1.2.0/24
acl mm src 10.12.0.0/16
acl cc src 10.16.0.0/16
acl ee src 10.17.0.0/16
acl ww src 10.18.0.0/16
acl hg src 10.19.0.0/16
acl gh src 10.20.0.0/16
acl nn src 10.22.0.0/16
acl kk src 10.23.0.0/16
acl ss src 10.24.0.0/16
acl bv src 10.25.0.0/16
acl cb src 10.40.0.0/16
http_access allow a1
http_access allow mm
http_access allow cc
http_access allow ee
http_access allow ww
http_access allow hg
http_access allow gh
http_access allow nn
http_access allow bv
http_access allow kk
http_access allow ss
http_access allow bv
http_access allow cb
# And finally deny all other access to this proxy
http_access allow localhost
http_access allow pcngroup-RB pcntime-RB
http_access allow webconfig_to_lan
http_access allow webconfig_lan
http_access deny all
I have now come to do this on 6.4, and have found that the squid.conf no longer exists in the same format.
The parsed files such as squid_lans.conf state that they are automatically created from the network configuration, so I assume that I don't want to add lines in here.
Pete Baldwin references adding an extra lan (You can add extra networks in /etc/clearos/network.conf) in the 6.x feature tracker (http://tracker.clearfoundation.com/print_bug_page.php?bug_id=96), however I don't know if this is the right place to add them, as the IPSEC vpn app has must have already added the routes to the routing table (you can ping the remote device, juts no http access).
Has anyone configured remote subnet access in squid on 6.4? Please could you suggest which file I should be adding the VPN subnets.
Thanks
David
Share this post:
Responses (11)
-
Accepted Answer
-
Accepted Answer
Hi Nick,
I added the remote subnets to the EXTRALANS section, ifdown & ifup eth5 (lan), service restart on firewall and squid. The squid_lans.conf now has two populated lines webconfig_lan and webconfig_to_lan with the subnets from the EXTRALANS field.
These sound like they are more to do with subnets that can access the webconfig pages, rather than be granted http_access.
If I add the rules into the squid.conf files, they don't seem to have taken effect, I don't know if this file is fully parsed as it was in 5.2.
So either need to specify http_access as well as webconfig (if the squid_lans is the correct place), or define the remote subnets elsewhere.
David -
Accepted Answer
Hi Nick,
I have been to one of the remote sites today, and they have internet access, therefore I need to redefine the problem: accessing http (such as a printer) which is in a connected subnet is not possible, although access to the external internet is working, therefore the problem is that squid does not appear to be 'directing' known subnet traffic 'back' within the internal network.
David -
Accepted Answer
-
Accepted Answer
Hi Nick,
I'm not sure that adding the extralans seems to have made much of a difference. I can see squid trying to connect to the router on the remote subnet:
1381405543.593 20086 10.1.1.20 TCP_MISS/000 0 GET http://10.19.1.1/ - DIRECT/10.19.1.1 -
If the internet is working from the remote subnet, then perhaps it is the firewall rules, and squid is configured correctly, When the VPN is loaded, I guess it adds an entry to the routing table / firewall rules.
The kernel routing table is aware that the subnet ip range is 'down' the VPN tunnel, as you can ping the remote devices perfectly, but just not view any http traffic.
David -
Accepted Answer
In the web browser I have put a do not use proxy exception for IP XX, so the lookup now goes to the default gateway (Clear) and should say 'put me down the vpn (as the ping packet) by looking at the routing rule', but before it gets to that stage it is being intercepted by the clear 'Please enable the proxy server settings with following values:' landing page (presumably because it is http traffic). Does this suggest it is likely to squid?
David -
Accepted Answer
-
Accepted Answer
I've had a peek in my VM. It looks like the subnets which access squid are controlled by /etc/squid/squid_lans.conf but this is created automatically. This could be similar to what started as bug 1215 and finished as bug 1268 only for VPN's (EXTRALANS) it should probably be a configurable option in the proxy. I wonder if it is worth raising a bug for it.
About the proxy intercepting traffic destined for you VPN, I am not sure of the solution. Perhaps an iptables rule in the PREROUTING chain to allow traffic before it gets redirected to squid. I don't know of squid can be configured directly. -
Accepted Answer
Hi Nick,
Just to update you, Tim B had a look at my system last night and we resolved the issue, it was down to the MTU on the eth port presumably being at the default of 1500, on the previous router it was set at 1458, we have reduced this to 1400, and the remote site worked. The 10.25 subnet was the only one one a different ISP to the rest, perhaps explaining the additional header information being attached to these packets.
Thanks for your suggestions and help :-) -
Accepted Answer
-
Accepted Answer
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »