{"id":988,"date":"2009-01-06T10:12:12","date_gmt":"2009-01-06T15:12:12","guid":{"rendered":"http:\/\/nuxx.net\/blog\/?p=988"},"modified":"2009-01-06T23:49:50","modified_gmt":"2009-01-07T04:49:50","slug":"binat-on-openbsds-pf-confuses-me","status":"publish","type":"post","link":"https:\/\/nuxx.net\/blog\/2009\/01\/06\/binat-on-openbsds-pf-confuses-me\/","title":{"rendered":"binat on OpenBSD’s pf Confuses Me"},"content":{"rendered":"

UPDATED:<\/strong> This is fixed. See the bottom of the post<\/a>.<\/p>\n

With the move to Wide Open West<\/a> for data service at home I now have up to three IPs available, all assigned via DHCP. In order to best use them and work around the Xbox Live problems I was having<\/a> I wanted to do the following:<\/p>\n

– Assign one IP to one interface, and NAT everything through it, like normal.
\n– Assign a second IP to a second interface, and use binat<\/a> to have my Xbox 360 to basically have its own public connection. (Sort of like being in the DMZ on a Linksys box.)
\n– Leave the third IP alone for times when I want a non-firewalled connection.<\/p>\n

While I have this set up, it doesn’t seem to be working. Here’s my current configuration. If anyone can tell me what I’m doing wrong or offer suggestions, please do so:<\/p>\n

– WebStar cable modem plugged into a switch.
\n– Two interfaces on the firewall fxp0<\/tt> and fxp1<\/tt> plugged into the switch.
\n– DHCP on fxp0<\/tt> and fxp1<\/tt> resulting in the following:<\/p>\n

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500<\/tt>
\n        lladdr 00:02:a5:da:e4:00<\/tt>
\n        groups: egress<\/tt>
\n        media: Ethernet autoselect (100baseTX full-duplex)<\/tt>
\n        status: active<\/tt>
\n        inet6 fe80::202:a5ff:feda:e400%fxp0 prefixlen 64 scopeid 0x1<\/tt>
\n        inet 74.199.15.37 netmask 0xfffff000 broadcast 74.199.15.255<\/tt>
\nfxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500<\/tt>
\n        lladdr 00:02:a5:da:e4:01<\/tt>
\n        media: Ethernet autoselect (100baseTX full-duplex)<\/tt>
\n        status: active<\/tt>
\n        inet6 fe80::202:a5ff:feda:e401%fxp1 prefixlen 64 scopeid 0x2<\/tt>
\n        inet 74.199.15.89 netmask 0xfffff000 broadcast 74.199.15.255<\/tt><\/p>\n

trashwall# route -n show<\/tt>
\nRouting tables<\/tt><\/p>\n

Internet:<\/tt>
\nDestination        Gateway            Flags   Refs      Use   Mtu  Prio Iface<\/tt>
\ndefault            74.199.0.1         UGS        7  3931950     -    48 fxp0<\/tt>
\n74.199.0\/20        link#1             UC         1        0     -    48 fxp0<\/tt>
\n74.199.0.1         00:01:5c:31:83:42  UHLc       1        0     -    48 fxp0<\/tt>
\n74.199.15.37       127.0.0.1          UGHS       0        0 33204    48 lo0<\/tt>
\n74.199.15.89       127.0.0.1          UGHS       0        0 33204    48 lo0<\/tt>
\n127\/8              127.0.0.1          UGRS       0        0 33204    48 lo0<\/tt>
\n127.0.0.1          127.0.0.1          UH         4    15344 33204    48 lo0<\/tt>
\n192.168.0\/24       link#3             UC         5        0     -    48 fxp2<\/tt>
\n192.168.0.2        00:16:cb:c5:16:2f  UHLc       0       51     -    48 fxp2<\/tt>
\n192.168.0.5        00:00:aa:a6:89:e0  UHLc       0        1     -    48 fxp2<\/tt>
\n192.168.0.6        00:11:d9:16:54:43  UHLc       0    63515     -    48 fxp2<\/tt>
\n192.168.0.10       00:17:f2:09:81:c6  UHLc       2   351684     -    48 fxp2<\/tt>
\n192.168.0.25       link#3             UHLc       1    52623     -    48 fxp2<\/tt>
\n192.168.1\/24       link#9             UC         0        0     -    48 wi0<\/tt>
\n224\/4              127.0.0.1          URS        0        0 33204    48 lo0<\/tt><\/p>\n

(IPv6 Stuff Omitted)<\/p><\/blockquote>\n

I’ve then got<\/a><\/tt> set up with the following very basic binat<\/tt> rule and nothing else. With this set I can ping both interfaces (fxp0<\/tt>: 74.199.15.37, fxp1<\/tt>: 74.199.15.89) from the outside:<\/p>\n

trashwall# cat \/etc\/pf.conf<\/tt>
\nbinat on fxp1 from 192.168.0.10 to any -> fxp1<\/tt><\/p><\/blockquote>\n

When I try to ping 208.83.71.138 (nuxx.net) from 192.168.0.10 (internal machine on the binat<\/tt> line above) I see the following on fxp0<\/tt>, the external interface on the firewall:<\/p>\n

trashwall# tcpdump -ni fxp0 host 208.83.71.138<\/tt>
\ntcpdump: listening on fxp0, link-type EN10MB<\/tt><\/p>\n

09:30:23.036562 192.168.0.10 > 208.83.71.138: icmp: echo request<\/tt>
\n09:30:24.036532 192.168.0.10 > 208.83.71.138: icmp: echo request<\/tt>
\n09:30:25.036758 192.168.0.10 > 208.83.71.138: icmp: echo request<\/tt>
\n09:30:26.036702 192.168.0.10 > 208.83.71.138: icmp: echo request<\/tt>
\n^C<\/tt>
\n70 packets received by filter<\/tt>
\n0 packets dropped by kernel<\/tt>
\ntrashwall#<\/tt><\/p><\/blockquote>\n

I shouldn’t be seeing a private, internal address going out of the firewall. My understanding of binat<\/tt>, from both the PF: Network Address Translation<\/a> article and the pf.conf<\/a><\/tt> man page say that it should be doing bidirectional mapping. To quote:<\/p>\n

A bidirectional mapping can be established by using the binat rule. A binat rule establishes a one to one mapping between an internal IP address and an external address. This can be useful, for example, to provide a web server on the internal network with its own external IP address. Connections from the Internet to the external address will be translated to the internal address and connections from the web server (such as DNS requests) will be translated to the external address. TCP and UDP ports are never modified with binat rules as they are with nat rules.<\/cite><\/p><\/blockquote>\n

I have also tried changing the binat<\/tt> line to be binat on fxp1 from 192.168.0.10 to any -> 74.199.15.89<\/tt> which is how the example is given (as opposed to the interface name, as in the man page) but that doesn’t make a difference.<\/p>\n

There’s one other thing to note, which I’m not sure is related or not. If I try to ping 208.83.71.138 with the outgoing interface set to 74.199.15.89 (fxp1<\/tt>) I see the pings go out with the right source address (74.199.15.89) but via the wrong interface (fxp0<\/tt>):<\/p>\n

trashwall# ping -I 74.199.15.89 208.83.71.138<\/tt>
\nPING 208.83.71.138 (208.83.71.138): 56 data bytes<\/tt>
\n--- 208.83.71.138 ping statistics ---<\/tt>
\n6 packets transmitted, 0 packets received, 100.0% packet loss<\/tt>
\ntrashwall#<\/tt><\/p>\n

trashwall# tcpdump -ni fxp0 host 208.83.71.138<\/tt>
\ntcpdump: listening on fxp0, link-type EN10MB<\/tt>
\n10:04:55.599135 74.199.15.89 > 208.83.71.138: icmp: echo request<\/tt>
\n10:04:56.607387 74.199.15.89 > 208.83.71.138: icmp: echo request<\/tt>
\n10:04:57.617325 74.199.15.89 > 208.83.71.138: icmp: echo request<\/tt>
\n10:04:58.627298 74.199.15.89 > 208.83.71.138: icmp: echo request<\/tt>
\n10:04:59.637270 74.199.15.89 > 208.83.71.138: icmp: echo request<\/tt>
\n10:05:00.647255 74.199.15.89 > 208.83.71.138: icmp: echo request<\/tt><\/p>\n

trashwall# tcpdump -ni fxp1 host 208.83.71.138<\/tt>
\ntcpdump: listening on fxp1, link-type EN10MB<\/tt>
\n10:04:55.624511 208.83.71.138 > 74.199.15.89: icmp: echo reply<\/tt>
\n10:04:56.626254 208.83.71.138 > 74.199.15.89: icmp: echo reply<\/tt>
\n10:04:57.636455 208.83.71.138 > 74.199.15.89: icmp: echo reply<\/tt>
\n10:04:58.645461 208.83.71.138 > 74.199.15.89: icmp: echo reply<\/tt>
\n10:04:59.657185 208.83.71.138 > 74.199.15.89: icmp: echo reply<\/tt>
\n10:05:00.667090 208.83.71.138 > 74.199.15.89: icmp: echo reply<\/tt><\/p><\/blockquote>\n

Is it possible that maybe I should just have both IPs bound to fxp0<\/tt>? This will require me to make the dhcp stuff quite a bit more custom, but maybe it’ll work?<\/p>\n

<\/a>UPDATE:<\/strong> This fixes it:<\/p>\n

binat on fxp1 from $reason to any -> fxp1<\/tt>
\nnat on fxp0 from $reason to any -> fxp1 static-port<\/tt><\/p><\/blockquote>\n

Thanks to for the help with this. I’ve now integrated into my normal config and will be updating the Trashwall<\/a> article soon to detail how I’m using the new WOW! connection at home<\/a>. See this post<\/a> for information on how this was used to make Xbox Live work properly (open NAT) from behind PF.<\/p>\n","protected":false},"excerpt":{"rendered":"

UPDATED: This is fixed. See the bottom of the post. With the move to Wide Open West for data service at home I now have<\/p>\n

Continue readingbinat on OpenBSD’s pf Confuses Me<\/span><\/a><\/div>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[],"class_list":["post-988","post","type-post","status-publish","format-standard","hentry","category-computers","entry"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/posts\/988","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/comments?post=988"}],"version-history":[{"count":13,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/posts\/988\/revisions"}],"predecessor-version":[{"id":1020,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/posts\/988\/revisions\/1020"}],"wp:attachment":[{"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/media?parent=988"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/categories?post=988"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nuxx.net\/blog\/wp-json\/wp\/v2\/tags?post=988"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}