No ping in subnet not working in subnets after update v2.27 core 168

Getting Started with IPFire Updates Trouble
1

Good morning dear friends, it is my first time in this blog, and I hope you understand what I am going to describe according to a problem I recently updated ipfire to v2.27 core 168, the problem is that before updating it I had some subnets and they arrived well to ipfire, my ipfire is in the 192.168.10.0 subnet, and I have other subnets in 192.168.20.0 and 192.168.30.0; being in a computer from subnets 20, 30 and 40 I can’t ping ipfire, and vice versa I can’t reach any subnet from ipfire, I’ve looked for options and created some rules but I can’t interconnect the subnets to ipfire, this happened to me later of the update with the pakfire.

Thanks for the help :slight_smile:

2

Hi Alejandro,
first welcome to the IPFire community.

To answer your question, we should have some more information.
How are the ‘subnets’ connected?
How is the green net of IPFire defined? 192.168.10.0/24, I suppose.

2 Likes
3

Hi,

presumed that you use something like asymmetric routing, your issue might be caused by Reverse Path Filtering (RPF) in Core Update 168 being tightened, so any network packet arriving on an interface where IPFire would have not routed replies back to will be dropped.

To validate this: What happens after you run these two commands on your IPFire machine?

sysctl net.ipv4.conf.default.rp_filter=2
sysctl net.ipv4.conf.all.rp_filter=2

They should become effective immediately, no reboot required or anything. Does this change anything to the behaviour you observe?

Thanks, and best regards,
Peter Müller

4 Likes
4

Hi Bernardo, thak u so mucho for u request, i resolve this withe the request of Peter

1 Like
5

Peter, your answer was very helpful to me and therefore to the solution of my problem, I did what you told me and it worked immediately, I will be more aware of these blogs here because I already see that they are very important, thanks friends :slight_smile:

1 Like
6

I don’t think this is the solution.
Peter’s suggestion just restores the situation before, but the comment in the git commit cited reads

sysctl: Use strict Reverse Path Filtering

The strict mode, as specified in RFC 3704, section 2.2, causes packets
to be dropped by the kernel if they arrive with a source IP address that
is not expected on the interface they arrived in. This prevents internal
spoofing attacks, and is considered best practice among the industry.

After a discussion with Michael, we reached the conclusion that
permitting users to configure the operating mode of RPF in IPFire causes
more harm than good. The scenarios where strict RPF is not usable are
negligible, and the vast majority of IPFire’s userbase won’t even
notice a difference.

7

Hello Bernhard, I understand your point of view according to what you quote, but before updating it worked fine for me, I did what Peter suggested and it worked immediately, I don’t know what you could suggest to make it work differently and how to solve it with the commands that Bernhard told me.
Greetings.

8

Your system seems to be one of ‘the scenarios where strict RPF is not usable are
negligible’.
But this is only a conclusion of the discussion of Peter and Michael.
The real impact isn’t known yet. But the specification in RFC 3704 suggests to use this strict mode, which is switched off by the commands Peter posted.

2 Likes
9

If I understand rfc 3704 and the implementation correctly, does it block all typical private subnets when I try to talk to it over the red interface?

10

No.
The main term is ‘routability’. If the red interface has a gateway configured ( which is usually true ) and this gateway reaches the private nets, the data flow isn’t blocked.
I’ve just tested this in my installation. The DOCSIS modem connected to red is reached by the private IP 192.168.100.1. Found no problems in the connection to the web interface of the modem.

2 Likes
11

Hi,

first of all, it is important to mention that the aforementioned sysctl commands are not persistent. A reboot will reset them to the default values IPFire comes with. Please add these commands to the firewall.local initscript to ensure they will be conducted on every boot.

Second: Actually, strict RPF is considered best practice for a long time, but alas never landed in IPFire. And since we did not know about its impact, we abstained from pushing the button for a long time - which is why you only get it now; I truly wished to have this earlier. Oh well.

There are situations (such as asymmetric routing) where strict RPF causes damage, and it needs to be reset to the “loose” mode (which has virtually no effect for IPFire systems) to make things work again. Other technical workarounds are possible for such setups, but are complicated and cannot be set up automatically, since knowledge of local network architecture is required.

Speaking of which, I would like to see a short network map of @alexrochagallo’s setup to understand it better. :slight_smile:

As @bbitsch already mentioned, no. The effect you mentioned would be caused by something like a bogon filter, which we don’t have in IPFire 2.x yet.

Hope to have some bits and pieces clarified.

Thanks, and best regards,
Peter Müller

3 Likes
12

That was exactly my thought. I was just confused because alexrochagallo supposedly can’t ping the other subnets from his ipfire.

2 Likes
13

The strict mode broke my tv setup. I use Bell Fibe for tv and right now, I’m using ipfire instead of the modem/router from Bell. I’ve configured ipfire to use vdsl for the red interface and setup two vlans: one for the internet and one for the tv. I’m also using igmpproxy running on ipfire.

This was all working just fine up until update 168. After the update, my Bell PVR would cut the channel I was watching after roughly 5 minutes. It took me a while to figure out what was going on, but eventually I discovered:

  1. the bell side was sending an igmp query
  2. the pvr’s reply wouldn’t be received
  3. the bell side would send a 2nd igmp query
  4. the pvr’s reply would again not be received
  5. the stream would drop

After more digging and searching the net, I landed on rp_filter being the culprit. I first tried to disable it completely for the tv vlan interface, but that didn’t work. Then I also disabled it for the green0 interface, which also didn’t work. Then I found another thread here from someone that set
net.ipv4.conf.all.rp_filter and net.ipv4.conf.default.rp_filter to ‘2’ to get logging for dropped packets (i think that’s what he did) to work again. I tried that and now igmp replies from the PVR to the queries sent from the Bell side are being received immediately. The result is the tv stream is stable once again.

My questions now are two fold:

  1. What is the side effect of setting those two kernel parameters to loose?
  2. What type of firewall rules do I need to make igmpproxy work with rp_filter enabled?
2 Likes
14

I am interested here as in many of my setups I have deployed more than one gateway ( Eg More than one IPFire ( As Ipfire out of the box does not allow multiple red :slight_smile:
E.G. IPFire1 = 192.168.100.1 IPfire2 = 192.168.100.2 ( in the same subnet and same physical lan / switch No Vlans) Servers may sit on for example 192.168.100.254 and 192.168.100.253 and the clients have either one gateway or another by a static IP allocation, DHCP may run on one of the 2 firewalls and of course these clients will get the gateway of the firewall providing the DHCP.

My question would this new enforcement of 3704 create any issues between clients / servers in the green , all on the same subnet, I am assuming not but for example I wanted to check a ping to either of my 2 firewalls from a client within green with one gateway(ipfire) as its default gateway or the other with either a static allocation or dhcp be able to ping and get a reply from both firewalls?

15

Hi,

apologies for my late reply.

If you don’t mind, I would defer to RFC 3704, sections 3 and 4, for the answer. The rationale and consequences of reverse path filtering are well described in there, I find, and probably provide you with a more holistic view on the situation.

One solution would be to leave RPF enabled in “strict” mode on all interfaces, and only set it to “loose” on interfaces requiring that. More on this idea below.

To be honest, I would like to know that myself. One reason why we abstained from RPF for so long is that it happens before any packet filtering layers, which means that there are no logs of dropped packets available. Implementing RPF on the packet filter level was considered, but dismissed quickly, as the variety of scenarios, particularly when it comes to VPN usage, was too complicated to cover (and test).

You can configure RPF on a per-interface basis through sysctl’s such as:

net.ipv4.conf.green0.rp_filter

This allows you to disable RPF on internal interfaces (or at least set it to “loose”, though the effect of that setting is minimal), while leaving it in “strict” mode on RED, to prevent external spoofing attempts of internal networks. That would probably be the best compromise in your case.

Do both IPFire machines have the same routing table as well? In this case, strict RPF should not cause any issues.

3704?

I am with you, and would not assume strict RPF disrupting anything either.

Thanks, and best regards,
Peter Müller

2 Likes
16

It looks like I was hit by same bug.
However I have the minimalist setup red-green with green being in a bridge on an APU.
From the APU after boot I cannot ping 8.8.8.8. After running those 2 commands I still cannot ping 8.8.8.8. However if I disconnect and reconnect wan cable ping will work.
Added those 2 commands in firewall.local but after reboot still cannot ping 8.8.8.8 unless I disconnect and reconnect the wan cable.

17

@jb68 , this looks like a problem with your WAN side.
Do you have a DHCP red connection?
If yes, how are the messages about DHCP reconnection after the reboot and after dis-/re-connect of the WAN cable?

1 Like
18

Hi Bernhard,
Thanks for responding, I do have an ISP connection, at least stated by DHCP message at boot and also in web GUI status, It said connected, show an IP and a Gateway.
However I cannot ping anything not even the Gateway.
After reconnect I get same IP most of the time but ping and internet starts to work. Before adding those 2 lines no matter what I did it didn’t work at all and I was close to send it to garbage.
I will try to setup a different ethernet, My unit is an APU pretty old, that had an old Ipfire got it updated about 6 months ago and no issues until last update. (168)
Unfortunately I cannot babysit this unit if power goes off so I need to figure out what is going on. I also updated to v169 ( unstable ) but didn’t fix anything.

19

Maybe as a work around you could use /etc/sysconfig/rc.local (which is executed after the boot) to stop and start again the red interface (see below), to obtain the same effect of de-branching and reconnecting the cable (I think a restart will not work here). Or, you could even test (*) with a ping and stop/start only in case of a failure. This does not fix the problem but should automate a bit more and avoid too much babysitting the machine.

/etc/rc.d/init.d/networking/red stop
/etc/rc.d/init.d/networking/red start

(*) Bash ping test tutorial

2 Likes
20

I too was bitten by this change, but perhaps there is a better way for me to do what I want without triggering RPF?

I have 5 IP addresses, the first IP is the primary RED interface and I have a DMZ NAT rule that passes normal services through to a server in the DMZ.
The other 4 IP addresses are listed as aliases in ipfire, so ifconfig shows a red0p0 and red0:0-3.
I have NAT rules to pass ALIAS0 to a DMZ address and remap port 443 to 9444 (this is arbitrary).
While external connections work just fine from the internet, masqueraded connections from the GREEN network do not route properly to the red0:0-3 and the packets are dropped.

Maybe there is a better way than configuring aliases to route IP addresses through IP fire to DMZ endpoints?

Thanks,

–Perry