Bug 11624 - IPFire uses wrong source interface for remote IPsec destinations
Summary: IPFire uses wrong source interface for remote IPsec destinations
Status: CLOSED WORKSFORME
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will affect an average number of users Minor Usability
Assignee: Assigned to nobody - feel free to grab it and work on it
QA Contact:
URL:
Keywords:
Depends on:
Blocks: IPSECBUGS
  Show dependency tree / graph
 
Reported: 2018-02-11 13:31 UTC by Peter Müller
Modified: 2022-02-19 19:28 UTC (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Müller 2018-02-11 13:31:41 UTC 
Setup:
- two IPFire machines (Core Update 117 and 118-testing)
- GREEN and ORANGE networks behind both machines
- connected via IPsec N2N.

In case one IPFire machine has to transmit data to the remote GREEN network (observed: remote syslogging, remote DNS queries), it chooses the local ORANGE network as packet source.

This is a pity since one normally does not want an ORANGE host to communicate with a GREEN network. IPFire should use the appropriate local network interface (in this case: GREEN) as a source instead.

This especially causes trouble in correlation with bug #11559.
Comment 1 Tom Rymes 2018-02-11 19:10:02 UTC 
Does the order of the subnets in the IPSec setup affect the behavior?

i.e.: Does "10.1.0.0/24,192.168.1.0/24" behave differently than "192.168.1.0/24,10.1.0.0/24"?
Comment 2 Michael Tremer 2018-02-11 23:54:14 UTC 
This is deliberate and the only solution how the firewall itself gets access to the remote network. We have to add an ugly source NAT and the order is GREEN first and then rest.

> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/patches/strongswan-ipfire.patch;h=7071983b8c6d246cbe6a62ceb98df8de48afb36a;hb=HEAD

Look for "Add source nat so also the gateway can access the other nets"

If the firewall is always NATed to the ORANGE IP address, then there is either a bug in ip_in_subnet or your GREEN IP address isn't in the left subnets.
Comment 3 Peter Müller 2018-04-09 19:36:04 UTC 
All right. Does not sound very great, but I can live with it.

Surprisingly, changing the netowrk order - as Tom suggested in #1 - changes the behavior.
Comment 4 Peter Müller 2018-04-23 16:27:02 UTC 
This problem occurs again, this time reordering the networks in IPsec WebUI did not change anything.

I now use a single tunnel between both machines, announcing GREEN and ORANGE on both sides. No matter how I put the networks, the firewall 2 blocks connections coming from the ORANGE interface of firewall 1, which is the source of that traffic indeed. No idea what to do here.

Reopening this. :-)
Comment 5 Michael Tremer 2018-04-24 12:13:15 UTC 
Can you post firewall rules here? I think you might just have a rule that blocks it all.
Comment 6 Peter Müller 2022-02-19 19:28:37 UTC 
Closing this as the problem disappeared, does not seem to affect a larger userbase, and I was unable to reproduce it. Please reopen, if necessary.