Red interface going down many times a day after martian connection

Have currently major problem on version203. It can be seen in the kernel-log.

Red interface ist going down many times a day after marsian connect to the ip of the red interface. Usually it take about 5 minutes until the red interface (dhpc given from fritzbox) is up again. Even private IPs from the local FritzBox-Network are classified as Marcian, with is shurly not true.

This is a very unwanted behaviour, since not at least only phone call via SIP are killed.

Would need urgent help on this problem. It appeared on the day, where I changed my fritzbox 5490 against a new 7690. The problem also is the same on a second location, where I also changed the fritzbox as mentioned above.

I moved this to a separate post thread as it appears to not be related to the previous thread that it was posted in from 6 years ago as there was no mention of multicast issue or keepalived problem.

Thank for moving the issue. However I have to correct myself and copy 3 log-lines here

04:03:02 kernel: IPv4: martian source 192.168.2.1 from 192.168.50.18, on dev green0
04:03:02 kernel: ll header: 00000000: 00 0d b9 4a fd 15 00 11 32 a9 d1 50 08 00
22:04:58 kernel: igb 0000:01:00.0 red0: igb: red0 NIC Link is Down
04:03:02 kernel: IPv4: martian source 192.168.2.1 from 192.168.50.18, on dev green0
04:03:02 kernel: ll header: 00000000: 00 0d b9 4a fd 15 00 11 32 a9 d1 50 08 00
22:04:58 kernel: igb 0000:01:00.0 red0: igb: red0 NIC Link is Down

My current idea is that this problem relates to the so called EEE function of the new FritzBoxes’ lan interfaces. Therefore solution my be to set this energy-saving thing to “off”, and set lan speed fix to 100Mbit or 1 Gbit. At the moment it seems to help. But will see in the next days. Please also move the post to the correct position.

To explain: 192.168.50.0/24 is the lan of the fritzbox (=red interface ist 192.168.50.x)

green is 192.168.2.0/24

Some traffic is allowed to pass from extern or 192.168.50.x to green.

I observed traffic from external, red, blue and green - doesn’t matter - each can shut down the red interface. Which leads to ipfire is unreachable and all servers/clients behind the ipfire following also. In practice, internet for clients behind the firewall is down, since the connection to the gateway 192.168.50.1 is dead.

Plugging of and in the cat-cable for the red interface help only temporarely.

Can you identify the two MACs from the ll header?
Why are the martians reported on the green interface, if 192.1168.50.18 is from the Fritzbox LAN(=IPFire’s red network )? Are there physical connections?

Hello,

This message suggests that there is a direct connection between your fritzbox lan (192.168.50.0/24) to the green0 lan (192.168.2.0/24) bypassing IPFire.

I would check for an improper cabling (or vlan) connection somewhere.

Regards,
Stephen

00 0d b9 4a fd 15 is the red interface of the IP-Fire.

00 11 32 a9 d1 52 ([50 08 00] is too long) is synology Rackstation red leg, which has also a green leg (00 11 32 a9 d1 50). But uses for both network cards the same gateway 192.168.2.1.

Therefore it is true that this may break from red to green. In addition on the synology there are in 2 virtual maschines (debian DNS-Server using green interface, and freepbx telefony-server using the red interface of the synology). Anyway the rackstation has its own firewall.

I see your point. But syno can have one gateway for all interfaces (2 of 4 are active). Maybe I should set here 192.168.50.1 instead of 192.168.2.1 for the common gateway?

And these two log-lines above are one example only, beside about 50 per day coming from blue or red or really external.

But in fact it becomes better after setting down the EEE-function of the FritzBoxes LAN interfaces. The ipfire red leg is not going offline any more.

Hello,

I think your common gateway is what’s causing the martians. You should set each interface on the synology to use the gateway for the subnet that it’s on (guessing here: synologyGreenLeg → gateway=192.168.2.1 and synologyRedLeg → gateway=192.168.50.1) and not have any static routes between the two subnets defined on the synology (i.e. don’t use the synology as a router let IPFire and FritzBox do that for their respective subnets).

This isn’t a suggestion for the red0 dropouts that you were having. It looks like you fixed that with your EEE-function change. Just an opinion on configuring the synology.

Regards,
Stephen

How are your devices connected? Physical and logical.
The basic design of IPFire means: red0 is connected to WAN ( untrusted internet ), the traffic of the WAN is routed and firewalled to the internal networks ( green0, blue0, orange0 ), the devices on LANs are connected solely by IPFire to the WAN.

The EEE function of the Fritzbox influences the frequency of establishment of WAN connection in IPFire only, IMO.

Connection are all physical via Layer2-Switch, devided into 3 different VLANs. Therefore red VLAN receives DHCP IPs from FritzBox, blue and green receive DHCP IPs from ipfire. Red is connected FritzBox LAN port, which means FritzBox establishes the Internet connection and IP-Fire is so far a on the red side a client.