v0.2.3 : Nat reflection

Changes

New feature : Nat reflection.

When you expose a service in a private network on a public network through NAT bidirectionnal or port-forward, your public IP will be redirect to the private host serving the service by replacing target IP adress with the private host IP.

Before

The problem appears when a client is located in the same network as the target server. Lets check what this config would do :

# ibdfw configuration extract 
Nat port-forward PUBLIC_IP:80 to SERVER_IP:80

# Example : 
# Nat port-forward 30.45.32.6:80 to 10.1.1.145:80

1. Clients TCP SYN is sent from CLIENT_IP to PUBLIC_IP
2. The gateway receive the SYN packet, and apply Nat bidirectionnal or Port-Forward rules, so it replaces target IP by SERVER_IP, packet is now from CLIENT_IP to SERVER_IP
3. Server now receive packet and try to reply SYN ACK to CLIENT_IP, as client and server are in the same network, server don't send its packets replies to gateway but directly to client.
4. Client receive a TCP SYN ACK from SERVER_IP to CLIENT_IP, but did never contact SERVER_IP, and still wait for PUBLIC_IP to answer its TCP SYN packet.

Now

Nat reflection feature allow gateway to masquerade traffic going to a network on a specific interface.

# ibdfw configuration extract 
Nat port-forward PUBLIC_IP:80 to SERVER_IP:80
Nat reflection PRIVATE_NETWORK/CIDR on PRIVATE_NETWORK_INTERFACE

# Example : 
# Nat port-forward 30.45.32.6:80 to 10.1.1.145:80
# Nat reflection 10.1.1.0/24 on eth1

1. Clients TCP SYN is sent from CLIENT_IP to PUBLIC_IP
2. The gateway receive the SYN packet, and apply Nat bidirectionnal or Port-Forward rules, so it replaces target IP by SERVER_IP, but it also replaces source ip by its own because of masquerading, packet is now from GW_IP to SERVER_IP,
3. Server now receive packet and replies SYN ACK to GW_IP
4. GW does the reverse matching and replaces source ip by PUBLIC_IP, and target IP by CLIENT_IP
5. Client receive a TCP SYN ACK from PUBLIC_IP to CLIENT_IP, and continue establishing connection with TCP ACK. Everything is fine.

The drawback is that the server is now "seeing" the gateway as client, and not the real client ip.

Breaking changes :

None

v0.2.2 : Nat exceptions

Changes

• Nat unidirectionnal and bidirectionnal now accepts exception to prevent masquerading when forwarding to these ip/networks
• Fixing root privileges requirements for explain and export subcommands.
• Better README

Breaking changes :

None

v0.2.1 : Enhanced security

Changes

• ibdfw is now published in snapcraft :
  
• Snap package is now in strict confinement mode
  Warning : Configuration directory is now /var/snap/ibdfw/common/conf.d instead of /etc/ibdfw/conf.d
• Better pre-flight checks for iptables access in confined mode only for subcommands that needs
• Removing root privileges requirements for subcommands that do not need.
• snap packages are now auto-built from snapcraft

Breaking changes :

• Configuration directory is now** /var/snap/ibdfw/common/conf.d instead of /etc/ibdfw/conf.d
  There is not automatic migration, you need to move your configuration files manually

how to install ibdfw

sudo snap install ibdfw

You can generate your first config file with :

ibdfw config | sudo tee /var/snap/ibdfw/common/conf.d/main.conf

When applying rules for the first time, you would have to connect firewall-control interface to ibdfw snap (error will be explicit, and will display the fixing command) :

ubuntu@fw:~$ sudo ibdfw apply
Could not use iptables. Please run:
  'sudo snap connect ibdfw:firewall-control'

v0.1.1-alpha : core features

ibdfw is packaged as a classic confinement snap package.

To install ibdfw :

wget https://github.com/InfraBuilder/ibdfw/releases/download/v0.1.1-alpha/ibdfw_0.1.1_amd64.snap
sudo snap install --classic --dangerous ibdfw_0.1.1_amd64.snap

You can then generate a config file with :

sudo ibdfw config > /etc/ibdfw/conf.d/main.conf

and display help with :

sudo ibdfw help`

Functionnal features :

• Default
• Output
• Input
• Forward
• Raw
• Nat