On Tue, Sep 20, 2016 at 04:05:21PM -0400, Ryan Brackenbury wrote: > Glad to see I'm not imagining things, and there really is some strange > behaviour going on. Do you know if there is a bug report or initiative to > fix this? I really like NPF, but I think changing the NAT port behaviour > would be a clear improvement. >
I'm not aware of any bug reports related to this issue. I don't know if anyone is actively working on NPF. > As for my case: I tried static, but had no luck. I wasn't getting any > connectivity. BINAT works well, at the cost of having the gateway > I'm out of ideas. Sorry. :/ > > essentially proxy both incoming and outgoing connections (not good if > you're running fail2ban, for example): > > map $ext_if dynamic 10.1.0.74 <-> 192.168.0.124 > > Cheers, > - brkt > > On Sun, Sep 11, 2016 at 6:03 PM, Eric Garver <[email protected]> wrote: > > > Hi brkt, > > > > I've also been using NPF and hit pretty much the same thing. > > > > On Sat, Sep 10, 2016 at 07:39:56PM -0700, brkt wrote: > > > I've been using NPF as a gateway router for my homelab for a number of > > weeks > > > now, after a positive experience using it+fail2ban on my homeserver. > > > > > > What I've run into however is some (to me) unexpected NAT behaviour. I > > > wanted to expose a homelab server entirely to my home lan. I assigned an > > > aliased IP onto the homelab gateway's external IP, and wanted set up NAT > > > forwarding to redirect all ports to the server (in this case 10.1.0.0/24 > > is > > > my homelab netseg, 192.168.0.0/24 is my home lan netseg): > > > > > > map $ext_if dynamic 10.1.0.74 <- 192.168.0.124 > > > > > > When I tried SSHing to 192.168.0.124 from my home lan, I ended up > > getting: > > > > > > ssh: connect to host 192.168.0.124 port 22: Connection refused > > > > > > However, explicitly forwarding *just* port 22 works: > > > > > > map $ext_if dynamic 10.1.0.74 port 22 <- 192.168.0.124 port 22 > > > > > > I set up a firewall on the destination box and decided to monitor what > > was > > > happening to the packets, and realized that the destination port for the > > > packets was being selected randomly when the port wasn't explicitly set. > > > This behaviour also applies when a specific port is set, or a range of > > ports > > > are set: > > > > I have tried mapping port ranges like you stated above and had the same > > results. Thanks for pointing out that they get mapped to a random port > > internally - I had not debugged that far. > > I ended up using the one to one port method that you mentioned. I only > > needed a handful of ports. > > > > > # maps port 22 to random dest port: > > > map $ext_if dynamic 10.1.0.74 <- 192.168.0.124 port 22 > > > # maps ports 22, 80, 6667 all to random dest ports > > > $port_range = { ssh, http, irc } > > > map $ext_if dynamic 10.1.0.74 <- 192.168.0.124 port $port_range > > > # map all ports to dest port 22 -- this one actually makes sense > > > syntactically (to me) > > > map $ext_if dynamic 10.1.0.74 port 22 <- 192.168.0.124 > > > > > > Is all this expected behaviour? If so, what is the correct way to map > > all or > > > a range of ports? I would really like to do DNAT this way, rather than > > > resorting to BINAT (which seems to work for exposing all ports, as > > needed). > > > To me, what would seem to make the most sense would be implicit port > > ranges > > > - the forwarded ports go to thei ridentical dest port, unless specified > > > otherwise. This is the kind of behaviour I've noticed when working with > > > iptables, where I've been able to set a range of incoming ports and also > > the > > > corresponding range of destination ports. > > > > Have you tried using the "static" keyword instead of dynamic? > > i.e. > > > > map $ext_if static 10.1.0.74 <- 192.168.0.124 > > > > I avoided this because I didn't want to map all ports. But that sounds > > like what you want. > > > > Pretty sure you'll still want the dynamic NAT toward the uplink/external > > for the other things behind the router. > > > > I have no idea how the dynamic and static NAT will interact. > > > > Good luck! > > Eric. > >
