For security reasons IPFire ignores ICMP Redirects because this can used for some nasty man in the middle attacs. If you want this you have to add an additional static route.
Oh, i thought ping IS ICMP (which works anyway).
An additional static route in IpFire? 
ping is only a small part of ICMP and allowed on IPFire but ICMP Redirect are ignored.
2 Likes
@arne_f
ok i see.
the only second static route that came into my mind was the reverse version of the one i have
host IP address / network: 10.1.148.0/24
gateway: 10.207.47.114
but that didn’t work.
i also tried ‘normal’ rules for ICMP, also without success.
Maybe no answers mean that ipfire cannot do that.
Or maybe germany isn’t allowed to export answers to other countries at the moment.
Hi,
I believe is a routing problem, your Fritzbox maybe have a layer 3 switch and this is the answer with this router is working.
To work with Ipfire Router, the solution is:
Var1.
-connect both green LAN and healthcare router to a layer 3 switch;
or
Var2.
-set a static route in the Ipfire Router to healthcare LAN (host IP address / network: 10.207.47.0/24 and gateway: 10.207.47.114);
-connect healthcare LAN and red LAN into a normal switch (Layer 2);
Last variant is less expensive.
It’s a fairly stale thread but I have come across just this situation in the past – and thought it worth explaining what I think is occurring. Since ipFire is on an APU2 and you’re hanging a switch off one of the green ports, the problem is very likely that you are getting asymmetric routing.
A few key points:
-
Your switch works on layer 2 (MAC address). That means that 10.1.148.x addresses can talk to each other without involving the APU2. (Remember that the WAN side of the router will have a 10.1.148.x address.)
-
The healthcare router is NATed and will have a default gateway assigned (10.1.148.100). If something on the healthcare side of the router initiates a connection, it will send all of its traffic to that gateway over layer 3 (IP address).
-
Since you can ping card readers from the green zone, you have set up the static route correctly.
What is failing is the TCP 3-way handshake. (It fails in both directions, BTW.) For simplicity, I’ll call a green address A and a card reader address B. In this example, A will try to initiate a TCP connection to B.
- A sends a SYN packet to B via ipFire (over L3), since it’s not a local address.
- ipFire registers the SYN and, using the static route, sends it to B, via the healthcare router.
- B responds with a SYN/ACK. It gets to the WAN port of the router and, instead of returning via ipFire, goes directly to A over the L2 switch. ipFire therefore never sees this SYN/ACK.
- A thinks that everything’s going fine and confirms the 3-way handshake with an ACK to B, which again goes over L3 via ipFire.
So, although the SYN, SYN/ACK, ACK 3-way handshake successfully occurred, the outward and return paths are different and step 2 (the SYN/ACK) bypassed ipFire’s connection tracking. This is the reason why the DROP_NEWNOTSYN messages were occurring and why the TCP connection subsequently fails to work: ipFire is blocking it. Pings and traceroutes are “stateless” so don’t establish a permanent connection – and even tcptraceroutes work fine.
I was able to confirm all of this using tshark/tcpdump. On my ipFire device (also an APU2), I only ever saw A > B traffic, never B > A. As a result of my experiences, my ipFire APU2 currently sits on the edge of my network and acts solely as a firewall. I leave routing/switching to other devices, which is probably how it should be.
Edit: Although probably a bit too late for the OP, a possible solution might have been to bridge two NICs on green, attach one directly to the healthcare router and the second to the switch. This would ensure that all traffic to/from the router must pass through ipFire. I wasn’t able to use this method myself due to the physical set-up in my house.
1 Like
It has been a while and basically instead of ipFire I have still a fritzbox running. Due to planned changes of the healthcare network i would prefer a solid firewall including VPN so i did some testing again.
The main changes in healthcare network is (if i understood correctly) that they wont use static IPs any more, instead it’s recommended to use healthcare (GIN) DNS servers for all internal network requests because many services will change IPs without being communicated. Hmm. (Also means all surfing the web requests are running over the healthcare provider.) Currently 2 (new) static routes are necessary but a dozen routes are recommended for future services.
Using an APU4C4 i bridged the GREEN interface as mentioned in the above topic to have all green traffic running over ipFire.
Sadly the effect is the same. While a fritzbox has no problem with static routes, ipFire isnt able to connect.(The bridge is working because I can ping the GIN router with its LAN IP. Yes, the GIN router has its own ‘internet’ connection directly to the healthcare network).
Somehow it looks like ipFire wouldnt do the route as expected.
I don’t think it can be a hardware issue but who knows?
Thanks for any ideas!
Try to put the GIN Router to the orange or blue network then routes should work from green.
1 Like
GREEN is 10.2.148.x, the GIN Router has 10.2.148.254.
(The GIN router doesnt belong to us of course)
Sorry, but I have no idea which Subnets i can use for orange then (blue is WLAN).
Damn. Same subnet is not good.
In this case the clients need the route not IPFire.
If this is needed you can only try to push routes via dhcp to the clients. (dhcp option 121 and 249)
1 Like
Oh my. Currently I’m using static IPs in Green.
It’s weired that it works with the fritzbox, ‘static route’ must be interpreted differently.
Thanks, I need to read a lil about DHCP.
Best option will be to run a DHCP on the Win Server i would say.