Routing issue with bridged connection

1

I had a problem setting up a wired to wireless bridge on my Raspberry Pi box - but that is now fixed - Wired to wireless bridge in Linux - but the consequence seems to be that the squid proxy server that was running on the box now fails - eg many things time out as a TCP_MISS. (See below: this seems to be an issue about packets being routed outside my network - connections inside my network work fine)

How can I set the squid server up to work again?

The eth0 has no ip4 address, the wlan0 has no ip4 address, br0 does. But they all have ip6 addresses - though I am not using ip6.

I can use ssh to login both into and out of the RasPi, and Squid requests are reaching it...

Update: Clearly I have some routing problem. Just pinged an external address from the RasPi box and five pings took 80244ms! No packets dropped though. My routing table looks perfectly normal...

pi@raspberrypi ~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.62.1    0.0.0.0         UG    0      0        0 br0
192.168.62.0    0.0.0.0         255.255.255.0   U     0      0        0 br0

Further update: I have no problem with routing packets inside my network but there is plainly a big issue with packets from this machine going externally.

adrianmcmenamin

Posted 2012-12-21T00:36:27.627

Reputation: 472

should add that I have restarted the Squid server and the problem persists – adrianmcmenamin – 2012-12-21T00:43:21.900

Answers

0

You are really going for the advanced setup here. I'm guessing if you ping your gateway, 192.168.62.1 you get something under 20ms? And pinging 8.8.8.8 (google) gives you 80 sec.

Run a traceroute 8.8.8.8

Your first hop should be quick to 192.168.62.1, second should be to your ISPs Gateway. Traceroute takes longer to complete than a normal ping so don't let that worry you.

If your first 2 hops are different, there could be a network loop, or even a QoS issue.

As for squid, are you running a forward or reverse proxy? Reverse proxy handles requests coming onto a server / network and redirecting them, etc. Forward proxy probably caches external facing requests and logs them, etc.

There is probably no reason why you can't run a proxy on a bridge, but I don't think it's ever done in practice, because a bridge is intended to blindly pass traffic, while a proxy does the opposite.

IPv6 is something you don't want or need at this point. Depending on your ISP and router setup it can provide basically direct (unNATed) access to devices on your network. I don't think it's causing your problem, but if you turn it off it eliminates it as an issue and security risk.

On your debian box, echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf

I do see a small issue with your routing table. You may have conflicting metrics. Normally, I think your gateway metric should be 0 which it is, but your LAN metric is also 0, I think it should be 1 or more.

I would try changing it. ip route del 192.168.62.0/24 dev br0 proto kernel scope link src 192.168.62.[your ip] metric 0 then ip route add 192.168.62.0/24 dev br0 proto kernel scope link src 192.168.62.[your ip] metric 2

Then try the pings and traceroutes again.

MattPark

Posted 2012-12-21T00:36:27.627

Reputation: 1 061

Pretty certain it's a DNS issue. Pings of numerical addresses work fine, pings of domain addresses take forever – adrianmcmenamin – 2012-12-21T18:05:09.477

Actually, have resolve the DNS issue now but the proxy (reverse) still not working. Have run squid on a machine like this before without difficulty so very puzzled as to what is up – adrianmcmenamin – 2012-12-21T18:29:04.393

Actually, it was the DNS issue, it's just I had set somethings in the `squid.conf' file when I was trying to fix it – adrianmcmenamin – 2012-12-21T18:54:10.073

Sweet... yeah always recommend pinging 8.8.8.8 rather than google.com You can always ping google.com after 8.8.8.8 works... So you made the change to /etc/resolv.conf? If it was a DNS issue, it should have been resolved automatically by DHCP. Did you make the change on the DHCP server or on the client? – MattPark – 2012-12-23T03:26:12.917