|
||||
Hello, and a belated welcome!
I'm going to guess that the inbound pass establishes state, so the outbound traffic is not tested. You could check to see if this is what is happening by either changing the outbound rule to a match rule, or adding no state to your inbound pass rule. |
|
||||
I've tested both, here's the output:
Code:
pass in on $int_if1 inet proto tcp from $client to $int_if1 port 8080 rdr-to $server port 80 no state pass out on $int_if1 inet proto tcp to $server port 80 received-on $int_if1 nat-to $int_if2 test# pfctl -nf /etc/pf.conf /etc/pf.conf:1: nat-to and rdr-to require keep state /etc/pf.conf:1: skipping rule due to errors /etc/pf.conf:1: rule expands to no valid combination Code:
pass in on $int_if1 inet proto tcp from $client to $int_if1 port 8080 rdr-to $server port 80 match out on $int_if1 inet proto tcp to $server port 80 nat-to $int_if2 test# tcpdump -n -i re1 port 80 tcpdump: listening on rl1, link-type EN10MB 00:48:26.814606 192.168.0.3.32836 > 192.168.1.2.80: S 2731610042:2731610042(0) win 16384 <mss 1440,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 2862910124 0> 00:48:27.086607 192.168.0.3.5015 > 192.168.1.2.80: S 3391433507:3391433507(0) win 16384 <mss 1440,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 3308540081 0> 00:48:31.621346 192.168.0.3.16056 > 192.168.1.2.80: S 1418429462:1418429462(0) win 16384 <mss 1440,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 1283736596 0> 00:48:31.875904 192.168.0.3.20977 > 192.168.1.2.80: S 840544532:840544532(0) win 16384 <mss 1440,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 1452155539 0> |
|
||||
I've spent at least six hours trying to make it work before starting this thread. Read the pf user's guide on Traffic Redirection (Port Forwarding), the pf.conf man page, i've taken a look at Peter Hansteen's tutorials, also tried the fwbuilder interface to see the fw compilation results:
Code:
# Rule 0 (NAT) match in on re0 proto tcp from 192.168.0.3 to 192.168.0.1 port 8080 rdr-to 192.168.1.2 port 80 match out on re0 proto tcp from 192.168.0.3 to 192.168.1.2 port 80 nat-to (re1) Code:
test# sysctl |grep net.inet.ip net.inet.ip.forwarding=1 net.inet.ip.redirect=1 Last edited by junk; 20th June 2019 at 01:35 PM. |
|
||||
I have recreated the problem. It is the redirection which causes the NAT translation issue.
If there is no redirection, NAT works as expected. For example, having the client reach out directly to the server on port 80. The PF User's guide has a section on combining nat-to and rdr-to in the Redirection chapter. https://www.openbsd.org/faq/pf/rdr.html#rdrnat |
|
||||
Hi jggimi,
The example from that section, that's what i've been basing mine on. You say the issue has to do with the redirection, do you mean the rdr-to rule should be excluded? Code:
pass in on 192.168.0.1 inet proto tcp from 192.168.0.3 to 192.168.1.2 port 80 nat-to 192.168.1.1 Code:
test# tcpdump -n -i re0 port 80 tcpdump: listening on re0, link-type EN10MB 16:00:56.201078 192.168.0.3.39157 > 192.168.1.2.80: S 1831632233:1831632233(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 396746662 0> (DF) 16:00:56.461130 192.168.0.3.40049 > 192.168.1.2.80: S 2135530915:2135530915(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 1695820090 0> (DF) Code:
test# tcpdump -n -i re1 port 80 tcpdump: listening on re1, link-type EN10MB 16:00:56.201134 192.168.1.1.64573 > 192.168.1.2.80: S 1831632233:1831632233(0) win 16384 <mss 1440,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 396746662 0> 16:00:56.201721 192.168.1.2.80 > 192.168.1.1.64573: S 3651808616:3651808616(0) ack 1831632234 win 5792 <mss 1460,sackOK,timestamp 6019177 396746662,nop,wscale 7> (DF) 16:00:56.201782 192.168.1.1.64573 > 192.168.1.2.80: R 1831632234:1831632234(0) win 0 (DF) 16:00:56.461183 192.168.1.1.63859 > 192.168.1.2.80: S 2135530915:2135530915(0) win 16384 <mss 1440,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 1695820090 0> 16:00:56.461661 192.168.1.2.80 > 192.168.1.1.63859: S 3653687898:3653687898(0) ack 2135530916 win 5792 <mss 1460,sackOK,timestamp 6019229 1695820090,nop,wscale 7> (DF) 16:00:56.461717 192.168.1.1.63859 > 192.168.1.2.80: R 2135530916:2135530916(0) win 0 (DF) Last edited by junk; 21st June 2019 at 09:30 PM. |
|
||||
The rdr-to in the FAQ is distinctly different from your initial test in one key way: the rdr-to and nat-to are both on the same interface. This is used on an internal network as part of a redirection/reflection solution.
I think what your seeing is related to this restriction discussion in the Redirection and Reflection section of the FAQ, where I've highlighted: Quote:
Last edited by jggimi; 21st June 2019 at 03:23 PM. Reason: clarity |
|
||||
pf user guide's example:
Code:
pass in on $int_if proto tcp from $int_net to egress port 80 rdr-to $server pass out on $int_if proto tcp to $server port 80 received-on $int_if nat-to $int_if Code:
pass in on $int_if1 inet proto tcp from $client to $int_if1 port 8080 rdr-to $server port 80 pass out on $int_if1 inet proto tcp to $server port 80 received-on $int_if1 nat-to $int_if2 This would be closer to what they say in pf's faq: Code:
int_if1 = 192.168.0.1 int_if2 = 192.168.1.1 client = 192.168.0.3 server = 192.168.1.2 pass in on $int_if1 proto tcp from $client to $int_if2 port 80 rdr-to $server pass out on $int_if1 proto tcp to $server port 80 received-on $int_if1 nat-to $int_if1 Code:
test# tcpdump -n -i re0 port 80 tcpdump: listening on re0, link-type EN10MB 19:42:08.928850 192.168.0.3.48966 > 192.168.1.1.80: S 1766645:1766645(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 56749928 0> (DF) 19:42:08.928944 192.168.1.1.80 > 192.168.0.3.48966: R 0:0(0) ack 1766646 win 0 test# tcpdump -n -i re1 port 80 tcpdump: listening on re1, link-type EN10MB [none] Quote:
Quote:
Last edited by junk; 21st June 2019 at 09:52 PM. |
|
||||
Hmm, if the VOIP AP is filtering access, you may be able to provision it to accept connections from the workstation. If not, I can think of two other ways which might accomplish this; ssh(1) port forwarding, or a Layer 7 TCP relay with relayd(8).
|
|
||||
The more I think about this ... I think PF should work as a NAT solution, if you are able to eliminate the redirect. Just have the client connect directly to the server. PF will translate the sending address and port, and keep track of the stateful session.
|
|
||||
I tried another access point and was able to access it directly 192.168.0.3 ->
192.168.1.3 so the problem must be related to the previous access point... hahah! i can't believe it! I'm so sorry. Thanks anyway!... Last edited by junk; 22nd June 2019 at 01:48 PM. |
|
||||
This also works now:
Code:
int_if1 = 192.168.0.1 int_if2 = 192.168.1.1 client = 192.168.0.3 server2 = 192.168.1.3 pass in on $int_if1 inet proto tcp from $client to $int_if1 port 8080 rdr-to $server2 port 80 pass out on $int_if1 inet proto tcp to $server2 port 80 received-on $int_if1 nat-to $int_if1 #(or even $int_if2) Code:
test# tshark -t ad -r re0.dump 1 2019-06-22 17:27:32.222346 192.168.0.3 → 192.168.0.1 TCP 34249 8080 34249 → 8080 [SYN] Seq=0 Win=16384 Len=0 MSS=1460 SACK_PERM=1 WS=64 TSval=1574527048 TSecr=0 2 2019-06-22 17:27:32.228595 192.168.0.1 → 192.168.0.3 TCP 8080 34249 8080 → 34249 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1440 SACK_PERM=1 TSval=48477 TSecr=1574527048 WS=2 3 2019-06-22 17:27:32.228741 192.168.0.3 → 192.168.0.1 TCP 34249 8080 34249 → 8080 [ACK] Seq=1 Ack=1 Win=16384 Len=0 TSval=1574527048 TSecr=48477 4 2019-06-22 17:27:32.229366 192.168.0.3 → 192.168.0.1 HTTP 34249 8080 GET / HTTP/1.1 [Packet size limited during capture] 5 2019-06-22 17:27:32.232756 192.168.0.1 → 192.168.0.3 TCP 8080 34249 8080 → 34249 [ACK] Seq=1 Ack=383 Win=6864 Len=0 TSval=48478 TSecr=1574527048 6 2019-06-22 17:27:32.238640 192.168.0.1 → 192.168.0.3 HTTP 8080 34249 HTTP/1.0 302 Redirect [Packet size limited during capture] ... Code:
test# tshark -t ad -r re1.dump 1 2019-06-22 17:27:32.222418 192.168.0.3 → 192.168.1.3 TCP 34249 80 34249 → 80 [SYN] Seq=0 Win=16384 Len=0 MSS=1440 SACK_PERM=1 WS=64 TSval=1574527048 TSecr=0 2 2019-06-22 17:27:32.228550 192.168.1.3 → 192.168.0.3 TCP 80 34249 80 → 34249 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=48477 TSecr=1574527048 WS=2 3 2019-06-22 17:27:32.228794 192.168.0.3 → 192.168.1.3 TCP 34249 80 34249 → 80 [ACK] Seq=1 Ack=1 Win=16384 Len=0 TSval=1574527048 TSecr=48477 4 2019-06-22 17:27:32.229408 192.168.0.3 → 192.168.1.3 HTTP 34249 80 GET / HTTP/1.1 [Packet size limited during capture] 5 2019-06-22 17:27:32.232710 192.168.1.3 → 192.168.0.3 TCP 80 34249 80 → 34249 [ACK] Seq=1 Ack=383 Win=6864 Len=0 TSval=48478 TSecr=1574527048 6 2019-06-22 17:27:32.238592 192.168.1.3 → 192.168.0.3 HTTP 80 34249 HTTP/1.0 302 Redirect [Packet size limited during capture] ... Last edited by junk; 22nd June 2019 at 04:30 PM. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
network address translation | bsdsource | OpenBSD Security | 12 | 1st October 2016 10:36 PM |
PF and NAT: Specify SRC IP Address? | jasonvp | FreeBSD Security | 5 | 25th November 2015 08:04 PM |
Other Open-source typeface “Hack” brings design to source code | J65nko | News | 1 | 31st August 2015 03:06 PM |
MAC address to IP | rex | FreeBSD General | 9 | 11th November 2008 07:06 PM |
Asking about IPv6 address | berlowin | Off-Topic | 2 | 9th July 2008 02:39 AM |