Bug 12280 - responses from Squid instances behind IPsec connections are missing
Summary: responses from Squid instances behind IPsec connections are missing
Status: CLOSED WORKSFORME
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will only affect a few users Major Usability
Assignee: Michael Tremer
QA Contact: Peter Müller
URL:
Keywords: Security
Depends on:
Blocks: IPSECBUGS
  Show dependency treegraph
 
Reported: 2020-01-26 17:06 UTC by Peter Müller
Modified: 2020-04-11 15:04 UTC (History)
0 users

See Also:


Attachments
iptables TRACE output of accessing the remote Squid via telnet from the firewall itself (55.62 KB, text/plain)
2020-01-26 17:06 UTC, Peter Müller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Müller 2020-01-26 17:06:45 UTC
Created attachment 730 [details]
iptables TRACE output of accessing the remote Squid via telnet from the firewall itself

Using a remote Squid proxy behind and IPsec N2N connection as an upstream proxy is not possible because its responses are not making it back to the firewall:

> [root@maverick ~]# telnet 10.1.0.2 3128
> Trying 10.1.0.2...
> Connected to 10.1.0.2.
> Escape character is '^]'.
> GET /
> (long delay which is eventually result in a timeout)
> (after pressing Enter again, the following line appears)
> Connection closed by foreign host.

Oddly enough, executing the same command on a machine within the GREEN network works fine. IPS is disabled (enabling it makes no difference except for traffic being emitted to the internet directly if no SNAT is configured, see #12257), there is no remote packet filter in place denying these connections.

Attached is the iptables TRACE output, where 85.XXX.XXX.XXX is the public IP address of the ppp0 interface on the local firewall, 185.XXX.XXX.XXX is the public IP address of the remote IPsec destination, 10.1.0.2 is the IP of the Squid instance behind the IPsec tunnel, and 10.0.0.1 the local GREEN IP address.

Oddly enough, ping and SSH access through the IPsec connection work fine.

This problem is reproducible by using IPFire machines on both sides of the IPsec tunnel, so it is not related to any OpenBSD behaviour. :-)
Comment 1 Peter Müller 2020-04-11 15:04:44 UTC
Unfortunately, this problem cannot be reproduces any more. :-/