Firewall log entries CT_INVALID

Security Firewall Rules
1

For test purposes I have set up a Linux PC as router. The PC has 2 network cards with static IP addresses, the one from the greeen network, the other from a test network. In IPFire I have set a static route into the test network:
green network: 192.168.0.0/24
test network: 192.168.1.0/24
router PC: 192.168.0.250 connected to green, 192.168.1.192 connected to test network
static route in IPFire: network 192.168.1.0/24 gateway: 192.168.0.250

I can ping PCs behind the router from the green network, nothing else works. The firewall log shows entries with DROP_CTINVALID. In a separate environment (PC – router – PC) all is working as expected, in both directions.

What do I have to set for this to work?

Thanks in advance.
Krause

2

Hi,

unfortunately, I am not really sure if I understood your network setup correctly. May I ask you to draw a simple diagram of it, and post that here?

In particular, I did not quite get where the “test” network is located logically, and what role the “router in the green network” plays.

While I don’t think these are relevant for your problem, please post them here as well.

Thanks, and best regards,
Peter Müller

3

Thanks for your reply.

This is my test environment:

Test
Test1184×667 19.5 KB

That works, full access from PC1 to the PC in the test network:

Test2
Test2863×468 15.6 KB

What I want to accomplish is to have access from PCs in the green network to PCs in the test network and vice versa.

Krause

4

If Router has vpn capability, you can configure vpn.

Then, pc1 (.0 subnet) will vpn into the router and get access to the test pc (.1 subnet).

5

No, the router has no vpn. It is a simple Ubuntu machine, and we don’t want to spend a lot of time to configure it. We did this because we want to access customer PCs with their final configuration.

6

So it is not a router but an ubuntu pc with two nics.

If so, then you can issue iptables commands to allow traffic from .0 to .1 subnet

7

Those optables commands need to be run on tbe ubuntu “router” as far as i understand.

Any traffic from .0 to .1 doesn’t go via IPFire so it doesn’t ay any part in this.

8

I guess my ubuntu “router” is set up correctly, because it works as expected in an environment without IPFire, see 2nd diagram. The difference is, in the installation with IPFire (1st diagram) the PCs in the green network have IPFire as default gateway and IPFire has a static route to the ubuntu router. In contrast to this without IPFire (2nd diagram) the PCs in the green network have my ubuntu router (192.168.0.250) as default gateway. So I think IPFire is already involved. My question is why ICMP from green to test network is working and nothing else, and only in this direction? What needs to be set to allow all traffic?

9

Re: second diagram

What’s the ip of pc1? its gateway?

10

@krause I tested your second diagram in proxmox …

created container pc1 (based on ubuntu 20.04 template)
root@pc1:~# ip route
default via 192.168.0.250 dev eth0 proto static
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.100

created container ubu (based on ubuntu 20.04 template)
iptables -A FORWARD -i eth1 -j ACCEPT
iptables -A FORWARD -o eth1 -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

root@ubu:~# ip route
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.250
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.129

created container testpc (based on ubuntu 20.04 template)
root@testpc:~# ip route
default via 192.168.1.129 dev eth0 proto static
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.200

From pc1
root@pc1:~# ping -c2 192.168.1.200
PING 192.168.1.200 (192.168.1.200) 56(84) bytes of data.
64 bytes from 192.168.1.200: icmp_seq=1 ttl=63 time=0.104 ms
64 bytes from 192.168.1.200: icmp_seq=2 ttl=63 time=0.027 ms

From testpc
root@testpc:~# ping -c2 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_seq=1 ttl=63 time=0.077 ms
64 bytes from 192.168.0.100: icmp_seq=2 ttl=63 time=0.034 ms

Paul

11

In the 2nd diagram pc1 has an address from the green network and ubuntu as default gateway. In this scenario all is working, it was just to test the ubuntu routing settings.
In both scenarios ubuntu has the same settings.

12

I’m having the same issue. I’m using a TP-Link ER605 router to deploy VLANs on the ipFire Green network. I am writing this from a PC connected to the ER605. Internet access works fine. I can ping other devices on the Green network. I can access the ipFire GUI on its Green ip address. I cannot access the Windows file server, nor the intranet on Green. The firewall log shows lots of DROP_CTINVALID and DROP_NEWNOTSYN messages. ipFire appears to be blocking legitimate traffic on Green. IPS is not running on Green. Creating a rule to Allow All from the Green IP of the ER605 to the Windows file server, for example, does not fix the problem. Traffic is still blocked by ipFire.

13

I took the ER605 back to the lab to replicate and troubleshoot the problem. However, in the lab, I cannot replicate the problem. My lab ipFire is runnning the same Core version of ipFire and I restored the field config from backup to the lab ipFire. The lab firewall log has no DROP-CTINVALID entries and I can access network resources on the Green network. The only difference between the setups is that the field ipFire has an Orange NIC with a “default DMZ” configuration (no hosts in the DMZ however). The lab only has 2 NICs, Green and Red. More to follow.

14

I think I am struggling with the same issue. I have narrowed my problem down to ipFire connection tracking being overly aggressive. When using ipFire as a gateway to another network, even with static routes and firewall rules, connection tracking will block traffic if it only sees 1 side with DROP-CTINVALID.

My Setup

I use opnsense as my primary router at home but wanted to test ipFire vpn performance head-to-head so I setup an ipFire VM.

Both routers are connected to the same LAN/GREEN network (192.168.3.0/24) where I have my main desktop (192.168.3.99). Opnsense LAN interface is 192.168.3.1 and ipFire GREEN interface is 192.168.3.15.

Each router also defines its own open VPN client network: 192.168.21.0/24 for opnsense and 192.168.15.0/24 for ipFire.

There are reciprocal static routes and firewall rules on both routers for the VPN networks.

Testing

When using ipFire as my desktop computer’s gateway, opnsense VPN clients cannot connect. Looking at the ipFire firewall logs I can see my icmp replies are blocked with DROP-CTINVALID. The icmp request came straight from opensense to the desktop which then replies using the ipFire gateway and is blocked.

Everything is working as expected when the desktop uses opnsense as its gateway. I can connect to either VPN and ping the desktop successfully. I cannot find any settings that allow me to modify the connection tracking in ipFire to fix this issue. Very frustrating as it took a while to figure out why this setup wasn’t working.