0

I am trying to forward packets to a firewall without using NATting in order to preserve the original destination IP.

The scenario is the following:

  • I have a physical server connected to the internet with multiple external IPs via only one physical network adapter.
  • This physical server is running as a hypervisor. One of the virtual machines is running pfSense as a firewall and should take care of all the port forwarding to the other VMs (which are in a different network which only the firewall has direct access to and does NATting for).
  • The idea is to forward / redirect incoming packets for the multiple external IPs to the pfSense firewall so I can set up the port forwarding rules only once in that central place.

The problem is that if I were to use NAT, I would of course replace the destination IP of the incoming packet with the firewall's IP before passing it on to the firewall. That works fine for just one external IP, but with multiple external IPs I would lose the information about which external IP was originally targeted, effectively limiting me to only one port forwarding across all external IPs.

Question: Is there a way to forward the packets to the pfSense firewall without changing the destination IP or while preserving this information somehow for use with the pfSense firewall?

I tried using the iptables mangle table and setting a mark / fwmark for the packets + using ip route and ip rule to redirect the package, but it does not seem to be working:

Hypervisor:
External IP 1       = 123.123.123.123
Firewall network IP = 10.0.0.1

pfSense firewall
Firewall network IP = 10.0.0.2

iptables -t mangle -A PREROUTING -d 123.123.123.123/32 -j MARK --set-mark 1
iptables -A FORWARD -d 123.123.123.123/32 -j ACCEPT
ip route flush table 1
ip route add table 1 default via 10.0.0.2
ip rule add fwmark 1 table 1

The ip rule does work:

# ip route get 1.1.1.1 mark 0
1.1.1.1 via 123.123.123.1 dev xenbr0 src 123.123.123.123 uid 0
    cache

# ip route get 1.1.1.1 mark 1
1.1.1.1 via 10.0.0.2 dev xenbr0 table 1 src 10.0.0.1 mark 1 uid 0
    cache

iptables shows me that these relevant rules do get properly executed, but when I run tcpdump on the hypervisor:

tcpdump -i any -n tcp and dst port 12345

then I only see the two entries for the incoming packet, not another set of two like I would when using DNAT.

tcpdump on pfSense does not show me anything:

tcpdump -i xn0 -n tcp and dst port 12345

At this point I am not sure if iptables or the ip route / rule part are even working, but I could not find a good way to test this.

I am open to different approaches, but I would like to keep the current network layout.

Thank you!

Improve this question
3
  • 1
    Is there any reason you can't do the NAT in pfSense as well? Optionally pass through the physical external network interface to the pfSense VM, and let it handle everything. That's a much simpler solution, and the standard way to set up a firewall.
    – dirkt
    Commented Sep 11, 2019 at 8:56
  • @dirkt I was considering setting up the external IPs (apart from the external machine IP) on the VM level inside the pfSense firewall VM, yes. However, the machine is not within my physical reach, and I do need at least one external IP (the external machine IP) outside a VM in case the VM has problems booting up. I just thought it was odd to have one IP on the hypervisor level and all the others inside a VM - looks a bit like a crooked topology. But I had physical access, that is probably what I would do.
    – plm
    Commented Sep 11, 2019 at 11:45
  • 1
    After thinking about this problem for hours on end and narrowing it down to the main issue - not being able to discern incoming traffic after forwarding the packets to the pfSense firewall if I chose to use NATting - I noticed that I could just add virtual / additional IPs to the pfSense WAN network adapter, allowing me to map traffic from external IPs to the additional IPs 1:1 (e.g. 123.123.123.123 => 10.0.0.2, 123.123.123.124 => 10.0.0.3, ...). This should be straightforward and does not include mangling / marking packets, so I will regard this workaround as the solution.
    – plm
    Commented Sep 11, 2019 at 11:51

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .