PF Nat is not forwarding to jail

msnoid

New Member


Messages: 5

I am using PF and cannot get packets forwarded to a particular jail.
I want data that comes into my base machine on port 4243 to be forwarded to my jail
that has a service that is listening on port 4243. I have verified with telnet that the jail
can receive data on that port.


Here is my pf.conf


Code:
ext_if="vtnet0"

#Public IP
IP_PUB="1.1.1.1" 

set block-policy return
scrub in on $ext_if all fragment reassemble
set skip on log

table <jails> persist
nat on $ext_if from <jails> to any -> ($ext_if:0)
rdr on $ext_if proto tcp from any to $IP_PUB port 4243 -> 10.10.0.2 port 4243
rdr-anchro "rdr/*"

block in all
pass out quick modulate state
antispoof for $ext_if inet
pass in inet proto tcp from any to any port ssh flags S/SA keep state


Any help would be greatly appreciated.
 
OP
M

msnoid

New Member


Messages: 5

Code:
set skip on log
was a typo

is actually

Code:
set skip on lo

I added the following:

Code:
pass in proto tcp to port 4243
pass out proto tcp to port {4243}

Still no luck.

I am reloading the rules with pfctl -f /etc/pf.conf, do I need to restart pf or the server?
 

rootbert

Well-Known Member

Reaction score: 152
Messages: 411

what is your setup - do you use bridge/vnet? maybe pflog + tcpdump show whats wrong...
 
OP
M

msnoid

New Member


Messages: 5

Setup:

I'm using Bastille to create the jails on a gcloud hosted instances.
I ran:
Code:
tcpdump -n -e -ttt -i pflog0

Didn't see anything when I tried to telnet from the outside. I tried restarting the VM as well.
Not sure about vnet. I'm not using anything of that name explicitly.
 

VladiBG

Daemon

Reaction score: 545
Messages: 1,182

On which interface and group is the IP address of "10.10.0.2" ? When you have skip on lo group pf will not perform on any lo interface which is member of that group.
 

cmoerz

Member

Reaction score: 36
Messages: 90

A few things I noticed:
  • You shouldn't need the pass out proto tcp to port {4243} since you already have a pass out quick modulate state.
  • there appears to be a typo: it's rdr-anchor, you wrote rdr-anchro "rdr/*" (I suppose, this should have been caught by a pfctl -nf <file>?)
Would it be feasible to at least temporarily remove the block in all? This way, you could confirm, that your inbound rule definition is not the culprit.
I assume you did test whether outbound nat is working properly? I.e. you can access outside hosts from within your jail?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,017
Messages: 38,467

You shouldn't need the pass out proto tcp to port {4243} since you already have a pass out quick modulate state.
It shouldn't be needed at all because the incoming traffic is statefull. Most services don't initiate connections so they don't need outgoing rules.

I'm using Bastille to create the jails on a gcloud hosted instances.
Bastille has specific commands for this. That's why you need to have the rdr-anchor in your rules.
Code:
root@armitage:~ # bastille rdr
Usage: bastille rdr TARGET [clear|list|(tcp|udp host_port jail_port)]
Using a command like bastille rdr <jailname> tcp 4243 4243 will add the redirection.
 

Lamia

Aspiring Daemon

Reaction score: 207
Messages: 770

Could you try setting up an alias on the host network interface with the private IP address?
ifconfig_vtnet0_alias0="inet 10.10.0.2 netmask 255.255.255.0"
 
OP
M

msnoid

New Member


Messages: 5

Ok, so I created a new jail, threw nginx in it and used bastille rdr nginx-jail tcp 80 80
This worked. But still nothing in regards to the other jail.
I used bastille rdr my-jail tcp 4243 4243 as suggested.
I tried redirecting another port 8080 to the jail with:
bastille rdr my-jail tcp 8080 4243
I doubled checked that I can reach it from the host and I can.
Not sure what else to check, any suggestions?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,017
Messages: 38,467

Can you post the output from bastille list?
 
OP
M

msnoid

New Member


Messages: 5

Everyone, thank you for your help. Turns out, it was my gcloud firewall settings.
 
Top