Re: PF bi-nat
On Thu, Feb 24, 2022 at 02:14:55PM +, Laura Smith wrote:
> Thanks David for your comprehesive reply. It looks like perhaps the match
> trick is the cleanest way.
BTW, IMO the descriptin and example in the man page of pf.conf is more
clear than the FAQ.
-Otto
>
>
> --- Original Message ---
>
> On Thursday, February 24th, 2022 at 11:27, David Gwynne
> wrote:
>
> > On Wed, Feb 23, 2022 at 04:55:05PM +, Laura Smith wrote:
> >
> > > I've never had occasion to use bi-nat before and I'm struggling a little
> > > to wrap my head around the concept.
> > >
> > > The OpenBSD FAQ (https://www.openbsd.org/faq/pf/nat.html) gives the
> > > following example:
> > >
> > > "pass on tl0 from $web_serv_int to any binat-to $web_serv_ext"
> > >
> > > However I'm not clear on how this fits into the overall filtering
> > > strategy ? i.e. building logically on the example above, how do I say
> > > "only allow inbound bi-nat for ports 80 & 443".
> > >
> > > The FAQ makes an obscure statement "TCP and UDP ports are never modified
> > > with binat-to rules as they are with nat rules.", which I'm guessing is
> > > where the answer lies. But I'm not clear what this means in context ?
> > >
> > > Thanks !
> >
> > turns out binat is syntactic sugar, so it can be understood in terms of
> >
> > nat and rdr rules. let's say 192.0.2.1 is your external ip, 10.0.0.1
> >
> > is your internal ip, and em0 is your external interface:
> >
> > dlg@ix ~$ echo 'pass on em0 inet from 10.0.0.1 to any binat-to 192.0.2.1' |
> > pfctl -vnf -
> >
> > pass out on em0 inet from 10.0.0.1 to any flags S/SA nat-to 192.0.2.1
> > static-port
> >
> > pass in on em0 inet from any to 192.0.2.1 flags S/SA rdr-to 10.0.0.1
> >
> > i read that as any connection to my external ip is forwarded to the
> >
> > backend, and any connection from my backend server is rewritten to
> >
> > appear as if it's coming from my external ip. this could be useful if
> >
> > you've got a small public ip address allocation (eg a /29) from an
> >
> > ISP and don't want to burn the network and broadcast addresses by
> >
> > putting them on an actual subnet. you would binat every public IP
> >
> > to a backend on a private IP instead. id personally use p2p tunnels
> >
> > from the router to each backend, but maybe MTU/MRU is precious too?
> >
> > anyway, in terms of policy, restricting this to ports 80 and 443
> >
> > looks a bit clumsy:
> >
> > dlg@ix ~$ echo 'pass on em0 inet from 10.0.0.1 to any port { 80 443 }
> > binat-to 192.0.2.1' | pfctl -vnf -
> >
> > stdin:1: port only applies to tcp/udp
> >
> > stdin:1: skipping rule due to errors
> >
> > stdin:1: port only applies to tcp/udp
> >
> > stdin:1: skipping rule due to errors
> >
> > stdin:1: port only applies to tcp/udp
> >
> > stdin:1: skipping rule due to errors
> >
> > stdin:1: rule expands to no valid combination
> >
> > stdin:1: port only applies to tcp/udp
> >
> > stdin:1: skipping rule due to errors
> >
> > stdin:1: port only applies to tcp/udp
> >
> > stdin:1: skipping rule due to errors
> >
> > stdin:1: rule expands to no valid combination
> >
> > stdin:1: rule expands to no valid combination
> >
> > dlg@ix ~$ echo 'pass on em0 inet proto tcp from 10.0.0.1 to any port { 80
> > 443 } binat-to 192.0.2.1' | pfctl -vnf -
> >
> > pass out on em0 inet proto tcp from 10.0.0.1 to any port = 80 flags S/SA
> > nat-to 192.0.2.1 static-port
> >
> > pass in on em0 inet proto tcp from any port = 80 to 192.0.2.1 flags S/SA
> > rdr-to 10.0.0.1
> >
> > pass in on em0 inet proto tcp from any port = 443 to 192.0.2.1 flags S/SA
> > rdr-to 10.0.0.1
> >
> > pass out on em0 inet proto tcp from 10.0.0.1 to any port = 443 flags S/SA
> > nat-to 192.0.2.1 static-port
> >
> > pass in on em0 inet proto tcp from any port = 443 to 192.0.2.1 flags S/SA
> > rdr-to 10.0.0.1
> >
> > yeah. im not sure the pass out rules are that useful in practice.
> >
> > if you had a default allow policy, then binat could make sense. you'd
> >
> > have a pass binat rule followed by block rules to filter out the
> >
> > exceptions to your default policy.
> >
> > another option could be using match and tags:
> >
> > dlg@ix ~$ cat /tmp/rules
> >
> > match on em0 inet from 10.0.0.1 to any binat-to 192.0.2.1 tag backend
> >
> > pass out on em0 tagged backend
> >
> > pass in on em0 inet proto tcp to port { 80 443 } tagged backend
> >
> > dlg@ix ~$ pfctl -vnf /tmp/rules
> >
> > match out on em0 inet from 10.0.0.1 to any tag backend nat-to 192.0.2.1
> > static-port
> >
> > match in on em0 inet from any to 192.0.2.1 tag backend rdr-to 10.0.0.1
> >
> > pass in on em0 inet proto tcp from any to any port = 80 flags S/SA tagged
> > backend
> >
> > pass in on em0 inet proto tcp from any to any port = 443 flags S/SA tagged
> > backend
> >
> > pass out on em0 all flags S/SA tagged backend
> >
> > dlg
>
Re: PF bi-nat
On Wed, Feb 23, 2022 at 04:55:05PM +, Laura Smith wrote:
> I've never had occasion to use bi-nat before and I'm struggling a little to
> wrap my head around the concept.
>
> The OpenBSD FAQ (https://www.openbsd.org/faq/pf/nat.html) gives the following
> example:
>
> "pass on tl0 from $web_serv_int to any binat-to $web_serv_ext"
>
> However I'm not clear on how this fits into the overall filtering strategy ?
> i.e. building logically on the example above, how do I say "only allow
> inbound bi-nat for ports 80 & 443".
>
> The FAQ makes an obscure statement "TCP and UDP ports are never modified with
> binat-to rules as they are with nat rules.", which I'm guessing is where the
> answer lies. But I'm not clear what this means in context ?
>
> Thanks !
turns out binat is syntactic sugar, so it can be understood in terms of
nat and rdr rules. let's say 192.0.2.1 is your external ip, 10.0.0.1
is your internal ip, and em0 is your external interface:
dlg@ix ~$ echo 'pass on em0 inet from 10.0.0.1 to any binat-to 192.0.2.1' |
pfctl -vnf -
pass out on em0 inet from 10.0.0.1 to any flags S/SA nat-to 192.0.2.1
static-port
pass in on em0 inet from any to 192.0.2.1 flags S/SA rdr-to 10.0.0.1
i read that as any connection to my external ip is forwarded to the
backend, and any connection from my backend server is rewritten to
appear as if it's coming from my external ip. this could be useful if
you've got a small public ip address allocation (eg a /29) from an
ISP and don't want to burn the network and broadcast addresses by
putting them on an actual subnet. you would binat every public IP
to a backend on a private IP instead. id personally use p2p tunnels
from the router to each backend, but maybe MTU/MRU is precious too?
anyway, in terms of policy, restricting this to ports 80 and 443
looks a bit clumsy:
dlg@ix ~$ echo 'pass on em0 inet from 10.0.0.1 to any port { 80 443 } binat-to
192.0.2.1' | pfctl -vnf -
stdin:1: port only applies to tcp/udp
stdin:1: skipping rule due to errors
stdin:1: port only applies to tcp/udp
stdin:1: skipping rule due to errors
stdin:1: port only applies to tcp/udp
stdin:1: skipping rule due to errors
stdin:1: rule expands to no valid combination
stdin:1: port only applies to tcp/udp
stdin:1: skipping rule due to errors
stdin:1: port only applies to tcp/udp
stdin:1: skipping rule due to errors
stdin:1: rule expands to no valid combination
stdin:1: rule expands to no valid combination
dlg@ix ~$ echo 'pass on em0 inet proto tcp from 10.0.0.1 to any port { 80 443 }
binat-to 192.0.2.1' | pfctl -vnf -
pass out on em0 inet proto tcp from 10.0.0.1 to any port = 80 flags S/SA nat-to
192.0.2.1 static-port
pass in on em0 inet proto tcp from any port = 80 to 192.0.2.1 flags S/SA rdr-to
10.0.0.1
pass in on em0 inet proto tcp from any port = 443 to 192.0.2.1 flags S/SA
rdr-to 10.0.0.1
pass out on em0 inet proto tcp from 10.0.0.1 to any port = 443 flags S/SA
nat-to 192.0.2.1 static-port
pass in on em0 inet proto tcp from any port = 443 to 192.0.2.1 flags S/SA
rdr-to 10.0.0.1
yeah. im not sure the pass out rules are that useful in practice.
if you had a default allow policy, then binat could make sense. you'd
have a pass binat rule followed by block rules to filter out the
exceptions to your default policy.
another option could be using match and tags:
dlg@ix ~$ cat /tmp/rules
match on em0 inet from 10.0.0.1 to any binat-to 192.0.2.1 tag backend
pass out on em0 tagged backend
pass in on em0 inet proto tcp to port { 80 443 } tagged backend
dlg@ix ~$ pfctl -vnf /tmp/rules
match out on em0 inet from 10.0.0.1 to any tag backend nat-to 192.0.2.1
static-port
match in on em0 inet from any to 192.0.2.1 tag backend rdr-to 10.0.0.1
pass in on em0 inet proto tcp from any to any port = 80 flags S/SA tagged
backend
pass in on em0 inet proto tcp from any to any port = 443 flags S/SA tagged
backend
pass out on em0 all flags S/SA tagged backend
dlg
Re: SPA112 VoIP with pf and NAT - States keeps open on address change
> On 07.02.2019, at 14:21, Stuart Henderson wrote: > > On 2019-02-06, Patrick wrote: >> My nat rule use the parenthesis and all other devices behind the >> firewall works fine. I think it’s more a specific issue with the SPA112. >> I have also set the ruleset optimization to conservative but in this >> case the generated state has just a longer time to live. This isn’t the >> problem because the SPA112 sends regular keep alive packets which reset >> the counter for the state. > > Setting to 'conservative' (i.e. hanging on to states for longer) can't > help with this. > > Using parentheses won't help either, that means "do a lookup at state > creation time", but you aren't getting a new state created because the > old one hasn't expired. > >> >> Here the related rules: >> pass out quick on egress inet from (vether0:network) nat-to (egress) >> modulate state >> pass in on egress inet proto udp from to (egress) port 5060 >> >> As I’m just reading again my rules. Is the modulate state the problem? >> Or will pf use keep state for UDP packets as the default? > > PF uses "keep state" by default, and "keep state" is required for NAT. > > I think your main options are: > > - use a *shorter* timeout for this rule (this can be set per-rule > and overrides the default from "set optimization") and have a port > forward rule so that incoming packets still work even when the > state has timed out > > - arrange a way to flush these states when the IP changes > > The first of these is probably easiest if you can do it .. > > Thanks for suggestions. I tried to change the timeouts but every time the state gets deleted the SIP server refused the new connection. I think because of the change of source port. Maybe it would work with static-port option. I choose option two and have created a cron job to reconnect my VDSL connection and flush the state table at 2am in the night. This moved the force termination after 24 hours to the night. I remember that the old firewall had a similar option and probably also deleted the state table at the same time. I didn’t noticed the disconnection of my SPA112 in the middle of the night. To recover quicker from a termination at day I have set the re-register timeout to 30 minutes and also runs a script every five minutes on the firewall to check the current public IPv4 address and the one in the state table for the SPA112 and if it not match delete the state. Best Regards, Patrick
Re: SPA112 VoIP with pf and NAT - States keeps open on address change
On 2019-02-06, Patrick wrote: > My nat rule use the parenthesis and all other devices behind the > firewall works fine. I think it’s more a specific issue with the SPA112. > I have also set the ruleset optimization to conservative but in this > case the generated state has just a longer time to live. This isn’t the > problem because the SPA112 sends regular keep alive packets which reset > the counter for the state. Setting to 'conservative' (i.e. hanging on to states for longer) can't help with this. Using parentheses won't help either, that means "do a lookup at state creation time", but you aren't getting a new state created because the old one hasn't expired. > > Here the related rules: > pass out quick on egress inet from (vether0:network) nat-to (egress) modulate > state > pass in on egress inet proto udp from to (egress) port 5060 > > As I’m just reading again my rules. Is the modulate state the problem? > Or will pf use keep state for UDP packets as the default? PF uses "keep state" by default, and "keep state" is required for NAT. I think your main options are: - use a *shorter* timeout for this rule (this can be set per-rule and overrides the default from "set optimization") and have a port forward rule so that incoming packets still work even when the state has timed out - arrange a way to flush these states when the IP changes The first of these is probably easiest if you can do it ..
Re: SPA112 VoIP with pf and NAT - States keeps open on address change
> On 06.02.2019, at 11:15, Sebastian Reitenbach > wrote: > > Am Mittwoch, Februar 06, 2019 10:57 CET, jum...@yahoo.de schrieb: > >> Hello, >> I have a Cisco SPA112 VoIP to connect my analog phone to my provider SIP >> system. Recently I replaced my Linux based (Fritzbox) with a OpenBSD 6.4 >> firewall. The firewall is connected to a vDSL modem and performs NAT for >> outgoing IPv4 connection. The connection to the SIP server from the SPA112 >> is a IPv4 with NAT via UDP port 5060. The connection works and I can see the >> NAT in the state table. I have configured NAT-Keepalive on the SPA112 to >> keep the state open. After 24 hours my provider terminate my connection and >> after established a new connection the firewall has a new public IPv4 >> address. >> After this change the SPA112 can't longer communicate to the SIP server >> because it's still using the old state with the old public IPv4 address. If >> I deleted the state manually on the firewall the force the SPA112 to >> register again it works. The SPA112 has also an automatism to re-register >> after 60 minutes. But without deleting the state the SPA112 will use again >> the old state/connection. >> From my point of view the SPA112 should use a new connection for the >> re-register or at least a new connection, if it detects the lost of the >> previous registration. But this problem doesn't exist with the old Linux >> based firewall. I can also see a lot of other NAT entries in the state table >> with the old public IPv4 address. Is there a feature of pf to delete all NAT >> entries with the no longer existing public IPv4 on a address change? >> Best Regards,Patrick > > some lines of pf.conf would be helpful. Do you have parentheses around your > interface name in the nat-to rule, like nat-to ($ext_if) > that should update the rules when addresses change, but I don't think that > will touch active states. > However, SIP and UDP might be problematic, since states are consulted first, > before the rules are traversed. Since UDP is stateless, PF only seems > sending/receiving IP and port, but with SIP the sending port always might be > 5060 as well, so it may match the existing state, even if the external IP > changed. > > Sebastian > Hi Sebastian, Thanks for your quick reply. My nat rule use the parenthesis and all other devices behind the firewall works fine. I think it’s more a specific issue with the SPA112. I have also set the ruleset optimization to conservative but in this case the generated state has just a longer time to live. This isn’t the problem because the SPA112 sends regular keep alive packets which reset the counter for the state. Here the related rules: pass out quick on egress inet from (vether0:network) nat-to (egress) modulate state pass in on egress inet proto udp from to (egress) port 5060 As I’m just reading again my rules. Is the modulate state the problem? Or will pf use keep state for UDP packets as the default? Best Regards, Patrick
Re: SPA112 VoIP with pf and NAT - States keeps open on address change
I think you need to show your pf rules. Did you make your firewall aware that your ISP is changing address ?
Re: SPA112 VoIP with pf and NAT - States keeps open on address change
Am Mittwoch, Februar 06, 2019 10:57 CET, jum...@yahoo.de schrieb: > Hello, > I have a Cisco SPA112 VoIP to connect my analog phone to my provider SIP > system. Recently I replaced my Linux based (Fritzbox) with a OpenBSD 6.4 > firewall. The firewall is connected to a vDSL modem and performs NAT for > outgoing IPv4 connection. The connection to the SIP server from the SPA112 is > a IPv4 with NAT via UDP port 5060. The connection works and I can see the NAT > in the state table. I have configured NAT-Keepalive on the SPA112 to keep the > state open. After 24 hours my provider terminate my connection and after > established a new connection the firewall has a new public IPv4 address. > After this change the SPA112 can't longer communicate to the SIP server > because it's still using the old state with the old public IPv4 address. If I > deleted the state manually on the firewall the force the SPA112 to register > again it works. The SPA112 has also an automatism to re-register after 60 > minutes. But without deleting the state the SPA112 will use again the old > state/connection. > From my point of view the SPA112 should use a new connection for the > re-register or at least a new connection, if it detects the lost of the > previous registration. But this problem doesn't exist with the old Linux > based firewall. I can also see a lot of other NAT entries in the state table > with the old public IPv4 address. Is there a feature of pf to delete all NAT > entries with the no longer existing public IPv4 on a address change? > Best Regards,Patrick some lines of pf.conf would be helpful. Do you have parentheses around your interface name in the nat-to rule, like nat-to ($ext_if) that should update the rules when addresses change, but I don't think that will touch active states. However, SIP and UDP might be problematic, since states are consulted first, before the rules are traversed. Since UDP is stateless, PF only seems sending/receiving IP and port, but with SIP the sending port always might be 5060 as well, so it may match the existing state, even if the external IP changed. Sebastian
SPA112 VoIP with pf and NAT - States keeps open on address change
Hello, I have a Cisco SPA112 VoIP to connect my analog phone to my provider SIP system. Recently I replaced my Linux based (Fritzbox) with a OpenBSD 6.4 firewall. The firewall is connected to a vDSL modem and performs NAT for outgoing IPv4 connection. The connection to the SIP server from the SPA112 is a IPv4 with NAT via UDP port 5060. The connection works and I can see the NAT in the state table. I have configured NAT-Keepalive on the SPA112 to keep the state open. After 24 hours my provider terminate my connection and after established a new connection the firewall has a new public IPv4 address. After this change the SPA112 can't longer communicate to the SIP server because it's still using the old state with the old public IPv4 address. If I deleted the state manually on the firewall the force the SPA112 to register again it works. The SPA112 has also an automatism to re-register after 60 minutes. But without deleting the state the SPA112 will use again the old state/connection. >From my point of view the SPA112 should use a new connection for the >re-register or at least a new connection, if it detects the lost of the >previous registration. But this problem doesn't exist with the old Linux based >firewall. I can also see a lot of other NAT entries in the state table with >the old public IPv4 address. Is there a feature of pf to delete all NAT >entries with the no longer existing public IPv4 on a address change? Best Regards,Patrick
Re: pf and nat
* Giancarlo Razzolini grazzol...@gmail.com [2014-03-24 15:46]: First of all, I hardly see why you want or need to use if-bound, since it most likely hurts pf performance. it doesn't. however, if-bound is stupid except very few cases, i. e. on encX. Secondly, the proper way of doing nat, is using match rules, not pass. sez who? nat-to on pass rules is perfectly fine. using a match rule is just more practical in most scenarios. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: pf and nat
Em 17-04-2014 15:08, Henning Brauer escreveu: * Giancarlo Razzolini grazzol...@gmail.com [2014-03-24 15:46]: First of all, I hardly see why you want or need to use if-bound, since it most likely hurts pf performance. it doesn't. however, if-bound is stupid except very few cases, i. e. on encX. Secondly, the proper way of doing nat, is using match rules, not pass. sez who? nat-to on pass rules is perfectly fine. using a match rule is just more practical in most scenarios. Yes Henning you're right. I replied in another mail this, I believe you didn't got it. I prefer match because of the flexibility you get. Also, I do work on firewalls with 2, 3 and sometimes, 4 different internet connections and dynamically switches between then upon availability. Using match is much easier in these cases, because you can have one anchor and just change the pass ... route-to rules. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: pf and nat
Em 24-03-2014 19:28, Alexander Hall escreveu: On 03/24/14 15:44, Giancarlo Razzolini wrote: Secondly, the proper way of doing nat, is using match rules, not pass. Why would you say that? 'pass ... nat-to ...' makes perfect sense to me. Using match was an easy transition from the old nat rules, but being *the* proper way, no way. /Alexander Yes, you are right. You can condense everything in one rule. But, I prefer using match, because I can decouple the nat part from the filter part. I can have a broader match rule that allow nat for the entire network and all the protocols and ports, and I can filter individually things with pass rules. One of the things that I love the most about unix is that there are many ways to do things. And you can do things the way you taste better. Sorry if I was too strong in my opinion. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: pf and nat
Em 18-03-2014 15:19, Friedrich Locke escreveu: Hi folks, i am studying pf and a doubt arose! Since my state policy if if-bound (set state-policy if-bound) i need two rules for each traffic i want to pass. Is that understanding right ? For instance, for nat i could : pass out on tl0 from dc0:network to any nat-to tl0 pass in on dc0 from dc0:network to any Is this understanding correct ? Or only the first rule is ok? Thanks. First of all, I hardly see why you want or need to use if-bound, since it most likely hurts pf performance. Secondly, the proper way of doing nat, is using match rules, not pass. And, even with match rules, you need 2 rules anyway: match out on tl0 from dc0:network to any nat-to (tl0), tl0, gw ip, whatever pass in on dc0 from dc0:network to any If you want better control of what passes in which interfaces, I believe you are better served using tags than using if-bound and always duplicating yourself. You're less error prone. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: pf and nat
On 03/24/14 15:44, Giancarlo Razzolini wrote: Secondly, the proper way of doing nat, is using match rules, not pass. Why would you say that? 'pass ... nat-to ...' makes perfect sense to me. Using match was an easy transition from the old nat rules, but being *the* proper way, no way. /Alexander
Re: pf and nat
Secondly, the proper way of doing nat, is using match rules, not pass. Why would you say that? 'pass ... nat-to ...' makes perfect sense to me. Using match was an easy transition from the old nat rules, but being *the* proper way, no way. I also believe that one-way-ism is disease. I don't need to prove the concept. Things change. One-way-ist's often succumb.
Re: pf and nat
Hello, you are right, you need the both rules. -- Best regards, Loïc BLOT, UNIX systems, security and network engineer http://www.unix-experience.fr Le mardi 18 mars 2014 à 15:19 -0300, Friedrich Locke a écrit : Hi folks, i am studying pf and a doubt arose! Since my state policy if if-bound (set state-policy if-bound) i need two rules for each traffic i want to pass. Is that understanding right ? For instance, for nat i could : pass out on tl0 from dc0:network to any nat-to tl0 pass in on dc0 from dc0:network to any Is this understanding correct ? Or only the first rule is ok? Thanks. [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
pf and nat
Hi folks, i am studying pf and a doubt arose! Since my state policy if if-bound (set state-policy if-bound) i need two rules for each traffic i want to pass. Is that understanding right ? For instance, for nat i could : pass out on tl0 from dc0:network to any nat-to tl0 pass in on dc0 from dc0:network to any Is this understanding correct ? Or only the first rule is ok? Thanks.
Re: Internet access on openvpn with PF and NAT
Hello mike You are blocking trafic after matching nat rule. Because you don't use quick keyword, your PF match the first rule, and next the second and next the third and to do third. In your firewall configuration you block nothing and you nat nothing. Better way is to write this: set skip on lo block in log pass out pass in quick on tun0 from 10.8.0.0/24 to any nat-to 37.x.x.x This allow outgoing traffic and incoming trafic from tun0 (+nat). Because PF is stateful, you don't have to allow return traffic from tun0 nated clients. If you want to allow some more incoming traffic, add new rules after the previous rules. -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr Le vendredi 28 juin 2013 à 23:50 -0500, Mike Parker a écrit : pf.conf set skip on lo pass in on tun0 from 10.8.0.0/24 to any nat-to 37.x.x.x block log pass block in on ! lo0 proto tcp to port 6000:6010 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Internet access on openvpn with PF and NAT
I am having trouble trying to route tun0 to em0 via nat. Maybe I've misread the nat section / examples in pf.conf man page The iptables way to do this was, iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 37.x.x.x I can access and ping both sides while connected to openvpn. But when I tried outside the network I get. --- 8.8.8.8 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms tcpdump -eni pflog0 rule 1/(match) block in on tun0: 10.8.0.6 8.8.8.8: icmp: echo request (DF) pf.conf set skip on lo pass in on tun0 from 10.8.0.0/24 to any nat-to 37.x.x.x block log pass block in on ! lo0 proto tcp to port 6000:6010 openvpn server.conf proto udp port 80 dev tun0 ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/private/server.key dh /etc/openvpn/dh2048.pem comp-lzo persist-key persist-tun keepalive 10 120 server 10.8.0.0 255.255.255.0 user _openvpn group _openvpn daemon push redirect-gateway def1 push dhcp-option DNS 8.8.8.8 verb 3 status /etc/openvpn/status.log log /etc/openvpn/openvpn.log
Using PF to NAT IPSec connections when network segments overlap (redux)
A while back I was wondering if there was a good way to deal with overlapping network addresses in OpenBSD when setting up site-to-site VPNs. At the time the best solution I could find was just to use relayd (which iirc is now called something else), which works but isn't pretty. I've since found a much better solution, and I want to write it down here so that the next guy doesn't have to spend a day tearing his hair out. First: if you're using a recent version of OpenBSD, and the other side is as well, you may as well try http://www.undeadly.org/cgi?action=articlesid=20090127205841 I haven't, but it looks like a neat solution. In my case, the opposite end of the link is using a Juniper NetScreen, and my firewall is OpenBSD 4.3. I mostly followed the guide here: http://fixunix.com/bsd/87865-nat-ipsec-openbsd-pf-isakmpd.html, which works generally but is wrong in a few particulars. In my case, my company bought another company and we needed to merge networks. Unfortunately, the remote company used 192.168.10.0/24, which was the network on our end that we needed to share. What we did was, the remote end picked an unused network (192.168.14.0/24) and I picked another unused network (192.168.15.0/24). We then set up ipsec to set up the flows: ipsec.conf: ike active esp from 192.168.15.0/24 to 192.168.14.0/24 \ local a.a.a.a peer b.b.b.b \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des group none \ psk keykeykey (can I just say, by the way, how awesome ipsec.conf is? because it is) Now, as in the guide, we're going to route through lo1 and perform our natting on that interface. However, we do *not* want to assign any IP from the 192.168.15.0/24 network to lo1. This is because we want packets coming in from the enc0 interface to get routed back out of the OpenBSD box, which will not happen if OpenBSD thinks it's the destination for that packet. We do this by assigning lo1 an IP that is completely unrelated to anything else we're doing. Fortunately rfc1918 is generous. I took 192.168.99.1 because I didn't really expect this to work when I tried it. It would be trivial to move out of 192.168/16 altogether, I suppose, but it's even more trivial to leave it where it is: # ifconfig lo1 create # ifconfig lo1 inet 192.168.99.1/32 # route add 192.168.14.0/24 192.168.99.1 # route add 192.168.15.0/24 192.168.99.1 The first route sends packets headed for the IPSec link over lo1, where they will have their source address rewritten. The second rule forces packets over lo1 again, where the proper address is restored. Finally, add the binat rule in pf.conf, and do your firewalling. If you're having trouble, see whether you have `set skip on lo0` or just `lo`. You want the former. I pass all traffic to my NAT address and apply the firewall rules after the NAT when they are checked leaving the lo1 interface: pf.conf: binat on lo1 inet from 192.168.10.0/24 to 192.168.14.0/24 - 192.168.15.0/24 pass on lo1 from any to 192.168.15.0/24 pass on lo1 proto tcp from any to 192.168.10.37 port 80 If everything's working, you should be able to follow packets from the internal interface (bge0, in my case) over lo1, into enc0, and out the external (bge1). Let me know if you find any errors. I'm not on the list, so please cc me.
Re: pf outbound nat load balancing issue
It would appear not as I tried to sign up to the openbsd-pf list today and it failed. Just as pf is doing, failing. And now I am failing by talking to myself :-) 2008/10/18 gm_sjo [EMAIL PROTECTED]: Is there a more suitable mailing list for this kind of query? Thanks
Re: pf outbound nat load balancing issue
Is there a more suitable mailing list for this kind of query? Thanks 2008/10/16 gm_sjo [EMAIL PROTECTED]: Forgot to mention, i'm running 4.3 release. 2008/10/16 gm_sjo [EMAIL PROTECTED]: Hi all, I have a very basic pf NAT setup for testing on my new firewall. The firewall has two PPPoE connections which are using multipath default routes to load balance. Load balancing works for non-NAT traffic, but NAT traffic is only going out via one link, not both.
pf outbound nat load balancing issue
Hi all,
I have a very basic pf NAT setup for testing on my new firewall. The
firewall has two PPPoE connections which are using multipath default
routes to load balance. Load balancing works for non-NAT traffic, but
NAT traffic is only going out via one link, not both.
I am wondering what the behaviour is of interface groups? How are they
load-balanaced/selected?
I have looked into outgoing load-balancing in the pf faq, but i'm not
sure this applies when you're using multipath default routes?
I have configured both PPPoE interfaces as a group called 'wan'. My
NAT rule is on this interface group name :-
-bash-3.2# cat /etc/pf.conf
scrub out on wan max-mss 1440
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
nat on wan from vlan1010:network to any - $some_external_nat_ip
rdr pass on vlan1010 proto tcp from any to any port ftp - 127.0.0.1 port 8021
anchor ftp-proxy/*
-bash-3.2# ifconfig wan
pppoe1: flags=8851UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST mtu 1492
dev: fxp1 state: session
sid: 0x6 PADI retries: 0 PADR retries: 0 time: 12:49:11
sppp: phase network authproto chap authname xxx.1
groups: pppoe wan egress
inet6 fe80::2e0:18ff:feca:bf15%pppoe1 - prefixlen 64 scopeid 0x15
inet 217.169.2.61 -- 81.187.81.72 netmask 0x
pppoe2: flags=8851UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST mtu 1492
dev: fxp2 state: session
sid: 0x6 PADI retries: 0 PADR retries: 0 time: 12:49:11
sppp: phase network authproto chap authname xxx.2
groups: pppoe wan egress
inet6 fe80::2e0:18ff:feca:bf15%pppoe2 - prefixlen 64 scopeid 0x16
inet 90.155.88.39 -- 81.187.81.72 netmask 0x
(both links are with the same ISP, with same endpoint IP)
-bash-3.2# route show -inet
Routing tables
Internet:
DestinationGatewayFlagsRefs UseMtu Interface
default0.0.0.1UGS 1 786060 - pppoe1
default0.0.0.3UGS 0 190688 - pppoe2
-bash-3.2# cat /etc/hostname.pppoe1
inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev fxp1 authproto chap
authname 'xxx.1' authkey 'xxx' group wan up
!route add default -mpath -ifp pppoe1 0.0.0.1
-bash-3.2# cat /etc/hostname.pppoe2
inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev fxp2 authproto chap
authname 'xxx.2' authkey 'xxx' group wan up
!route add default -mpath -ifp pppoe2 0.0.0.3
(second is 0.0.0.3 because endpoint IP is the same for both links,
this caused a problem when using 0.0.0.1 for both {eg, both routes
werent added} - working fine for non-nat traffic)
Thanks!
Re: pf outbound nat load balancing issue
Forgot to mention, i'm running 4.3 release. 2008/10/16 gm_sjo [EMAIL PROTECTED]: Hi all, I have a very basic pf NAT setup for testing on my new firewall. The firewall has two PPPoE connections which are using multipath default routes to load balance. Load balancing works for non-NAT traffic, but NAT traffic is only going out via one link, not both.
Re: Using PF to NAT internal addresses over an IPSec link
Well, I've got it. It turns out it's kind of easy, although not as pretty as it could be. Basically, you use relayd. The one caveat is that this means that from the OpenBSD box, you need to be able to talk to the remote, private IPs without binding to a particular address. In relayd.conf, you enable relays on a port-by-port basis, so you can't allow blanket access.
Re: Using PF to NAT internal addresses over an IPSec link
On Fri, Aug 15, 2008 at 01:24:59PM +0900, william dunand wrote: Hi, I tried to reproduce what you want in my testing environment and managed to make it work. What you have to do is : - In your ipsec.conf, add an rule from your local network to the distant 172.25.0.1 (this rule is needed in order to route the traffic to enc0) Did you need to configure this on both ends? If I add a flow routing my network to the remote IP the packets never seem to get to enc0; it looks like isakmpd is stuck trying to negotiate something with the remove end. From what I can tell I need an SA for packets to get routed over enc0. In ipsec.conf I have: ike active esp from A.B.C.D to 172.25.0.1 peer W.X.Y.Z \ main auth hmac-md5 enc 3des \ quick auth hmac-md5 enc 3des group none \ psk yarg which lets me ping 172.25.0.1 from A.B.C.D. To route packets to 172.25.0.1 I am using flow from any to 172.25.0.1 peer W.X.Y.Z This does create appropriate encap entries in the routing tables, but I never see anything hit enc0.
Re: Using PF to NAT internal addresses over an IPSec link
Of course, as it is a testing environment it is a lot easier to make it work for me... On the remote side, a configured something like this (I suppose they have something of this kind on the other side) : ike passive esp from 172.25.0.1 to A.B.C.D And on the local server side, all I have is : ike esp from any to 172.25.0.1 peer W.X.Y.Z Never tried to use the flow directives as you did. I suppose that if as you said you have correct encap routes, packets headed to 172.25.0.1 should definitely go through enc0, then if you set nat on enc0, it should work as it does for me. Could you paste and show us the output of netstat -rnf encap and also if possible your pf.conf ? Regards, William 2008/8/15 Toby Burress [EMAIL PROTECTED]: On Fri, Aug 15, 2008 at 01:24:59PM +0900, william dunand wrote: Hi, I tried to reproduce what you want in my testing environment and managed to make it work. What you have to do is : - In your ipsec.conf, add an rule from your local network to the distant 172.25.0.1 (this rule is needed in order to route the traffic to enc0) Did you need to configure this on both ends? If I add a flow routing my network to the remote IP the packets never seem to get to enc0; it looks like isakmpd is stuck trying to negotiate something with the remove end. From what I can tell I need an SA for packets to get routed over enc0. In ipsec.conf I have: ike active esp from A.B.C.D to 172.25.0.1 peer W.X.Y.Z \ main auth hmac-md5 enc 3des \ quick auth hmac-md5 enc 3des group none \ psk yarg which lets me ping 172.25.0.1 from A.B.C.D. To route packets to 172.25.0.1 I am using flow from any to 172.25.0.1 peer W.X.Y.Z This does create appropriate encap entries in the routing tables, but I never see anything hit enc0.
Re: Using PF to NAT internal addresses over an IPSec link
On Fri, Aug 15, 2008 at 05:09:08PM +0900, william dunand wrote:
Of course, as it is a testing environment it is a lot easier to make
it work for me...
On the remote side, a configured something like this (I suppose they
have something of this kind on the other side) :
ike passive esp from 172.25.0.1 to A.B.C.D
And on the local server side, all I have is :
ike esp from any to 172.25.0.1 peer W.X.Y.Z
Ah, okay. It doesn't look like I have the luxury of simply saying
'from any to IP', since the remote end refuses to set up the SAs
in that case. I will try to get the other end to allow something
like that, since it seems like a MUCH better solution than the rube
goldberg stuff I'm playing with now, but half the reason I'm stuck
is the other guy doesn't return emails...
Never tried to use the flow directives as you did. I suppose that if
as you said you have correct encap routes, packets headed to
172.25.0.1 should definitely go through enc0, then if you set nat on
enc0, it should work as it does for me.
Could you paste and show us the output of netstat -rnf encap and also
if possible your pf.conf ?
Encap:
Source Port DestinationPort Proto
SA(Address/Proto/Type/Direction)
172.25.0.1/32 0 A.B.C.D/32 0 0 W.X.Y.Z/esp/use/in
A.B.C.D/32 0 172.25.0.1/32 0 0 W.X.Y.Z/esp/require/out
172.25.0.1/32 0 default0 0 W.X.Y.Z/esp/use/in
default0 172.25.0.1/32 0 0 W.X.Y.Z/esp/use/out
The pf.conf is pretty complicated, but the relevant rules that get hit are:
ext_if=bge1
int_if=bge0
vpn_if=enc0
set ruleset-optimization none
set state-policy if-bound
set skip on { lo }
scrub all fragment reassemble reassemble tcp
nat on $vpn_if from 192.168.0.0/16 to any - A.B.C.D
nat on $ext_if from 192.168.0.0/16 to any - E.F.G.H
block drop
pass quick on $vpn_if
pass quick on $int_if
And then there are others that eventually let us out of $ext_if as well.
Re: Using PF to NAT internal addresses over an IPSec link
Toby,
Actually, I was initially using my local subnet address rather than
any, but I realized that if did so, this address could be seen on
the remote vpn server by looking at the flows table.
After setting the from any rule, I realized that, yes it was more or
less working as expected, but it was screwing the internal carp
configuration on the remote side when you use the remote local subnet
as a target rather than 172.25.0.1. So I think it's not a good idea
anyway.
So I decided to try to set it up your way, with a manual flow directive.
I could make it work using something like :
ike esp from A.B.C.D to 172.25.0.1. peer W.X.Y.Z
flow from my.local.subnet to 172.25.0.1 peer W.X.Y.Z type require
(note that I had to set require to make it work)
But again the local subnet appears if you look at the flows on the
remote servers, so that's not what you want.
If I use any in place of my local subnet address, it doesn't work
for some reason I don't understand yet, I am just losing track of my
packets...
So I guess that as you said, you should try to get more informations
about the remote side configuration.
I would still be interested in knowing the clean and mighty way to
hide your local subnet topography.
Maybe using an intermediate local interface may help, as it was
suggested by Marc-Andre.
Regards,
William
2008/8/15 Toby Burress [EMAIL PROTECTED]:
On Fri, Aug 15, 2008 at 05:09:08PM +0900, william dunand wrote:
Of course, as it is a testing environment it is a lot easier to make
it work for me...
On the remote side, a configured something like this (I suppose they
have something of this kind on the other side) :
ike passive esp from 172.25.0.1 to A.B.C.D
And on the local server side, all I have is :
ike esp from any to 172.25.0.1 peer W.X.Y.Z
Ah, okay. It doesn't look like I have the luxury of simply saying
'from any to IP', since the remote end refuses to set up the SAs
in that case. I will try to get the other end to allow something
like that, since it seems like a MUCH better solution than the rube
goldberg stuff I'm playing with now, but half the reason I'm stuck
is the other guy doesn't return emails...
Never tried to use the flow directives as you did. I suppose that if
as you said you have correct encap routes, packets headed to
172.25.0.1 should definitely go through enc0, then if you set nat on
enc0, it should work as it does for me.
Could you paste and show us the output of netstat -rnf encap and also
if possible your pf.conf ?
Encap:
Source Port DestinationPort Proto
SA(Address/Proto/Type/Direction)
172.25.0.1/32 0 A.B.C.D/32 0 0 W.X.Y.Z/esp/use/in
A.B.C.D/32 0 172.25.0.1/32 0 0
W.X.Y.Z/esp/require/out
172.25.0.1/32 0 default0 0 W.X.Y.Z/esp/use/in
default0 172.25.0.1/32 0 0 W.X.Y.Z/esp/use/out
The pf.conf is pretty complicated, but the relevant rules that get hit are:
ext_if=bge1
int_if=bge0
vpn_if=enc0
set ruleset-optimization none
set state-policy if-bound
set skip on { lo }
scrub all fragment reassemble reassemble tcp
nat on $vpn_if from 192.168.0.0/16 to any - A.B.C.D
nat on $ext_if from 192.168.0.0/16 to any - E.F.G.H
block drop
pass quick on $vpn_if
pass quick on $int_if
And then there are others that eventually let us out of $ext_if as well.
Re: Using PF to NAT internal addresses over an IPSec link
I have the following configuration: LAN_B--[openBSD+Pf+Nat+VPN]---(internet)---[OpenBSD+Pf+NAT+VPN]---[openBSD+Squid]---LAN_A http://bsdsupport.org/ , setting up Ipsec over GRE on OpenBSD I can ping a host from LAN_A to a host on LAN_B I hope this can Help ! Original-Nachricht Datum: Wed, 13 Aug 2008 16:41:20 -0400 Von: Toby Burress [EMAIL PROTECTED] An: misc@openbsd.org Betreff: Using PF to NAT internal addresses over an IPSec link I have an IPSec connection set up to an external site, over which I have no control and whose topololgy I know nothign about (i.e. I don't know what subnets they use, etc.) Using ipsecctl, I have one flow set up, from my external IP A.B.C.D to an internal IP on their side, 172.25.0.1. I can ping 172.25.0.1 from the OpenBSD box, so IPSec is working fine. What I want to do is allow any machine from my internal networks to reach 172.25.0.1. What I would like to do is set up NAT, so that packets headed to the OpenBSD box from anywhere on my network get translated to A.B.C.D, which is then sent over the VPN connection. Unfortunately it looks like PF only applies NAT transforms when packets leave interfaces, not when they enter them, so packets come into the OpenBSD box with their private IPs, get routed out the interface associated with the default route, and only then get rewritten. Is there a better way to do this? I would like to be able to change which hosts on my side can go over the IPSec connection without having to coordinate with the other company, and without having to expose internal IP information. If you reply to the list please cc me as I am not subscribed. -- Pt! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine f|r Alle: http://www.gmx.net/de/go/messenger03
Re: Using PF to NAT internal addresses over an IPSec link
Hey List ! ... Interesting... I was about to send an e-mail on the list regarding this same question : aka: Best practice on NAT over IPsec... or how to do it correctly ?!?!?!? May I can suggest you to try something... : ( that what I will try anyway somewhere next week or so... ) Create a Loopback interface on one of your BSD and try to NAT on this 'lo' interface ... from that nat, adjust your pf to block all from lan A to lab B except from NAT ...and well, I think it should work ! any other suggestion to try or any ''already working here' ' notes that someone can post ? Regards, M-A Jorge Valbuena wrote: I have the following configuration: LAN_B--[openBSD+Pf+Nat+VPN]---(internet)---[OpenBSD+Pf+NAT+VPN]---[openBSD+Squid]---LAN_A http://bsdsupport.org/ , setting up Ipsec over GRE on OpenBSD I can ping a host from LAN_A to a host on LAN_B I hope this can Help ! Original-Nachricht Datum: Wed, 13 Aug 2008 16:41:20 -0400 Von: Toby Burress [EMAIL PROTECTED] An: misc@openbsd.org Betreff: Using PF to NAT internal addresses over an IPSec link I have an IPSec connection set up to an external site, over which I have no control and whose topololgy I know nothign about (i.e. I don't know what subnets they use, etc.) Using ipsecctl, I have one flow set up, from my external IP A.B.C.D to an internal IP on their side, 172.25.0.1. I can ping 172.25.0.1 from the OpenBSD box, so IPSec is working fine. What I want to do is allow any machine from my internal networks to reach 172.25.0.1. What I would like to do is set up NAT, so that packets headed to the OpenBSD box from anywhere on my network get translated to A.B.C.D, which is then sent over the VPN connection. Unfortunately it looks like PF only applies NAT transforms when packets leave interfaces, not when they enter them, so packets come into the OpenBSD box with their private IPs, get routed out the interface associated with the default route, and only then get rewritten. Is there a better way to do this? I would like to be able to change which hosts on my side can go over the IPSec connection without having to coordinate with the other company, and without having to expose internal IP information. If you reply to the list please cc me as I am not subscribed.
Re: Using PF to NAT internal addresses over an IPSec link
Hi, I tried to reproduce what you want in my testing environment and managed to make it work. What you have to do is : - In your ipsec.conf, add an rule from your local network to the distant 172.25.0.1 (this rule is needed in order to route the traffic to enc0) - Add a nat rule on enc0 in your pf.conf. Something like : nat on enc0 from !($ext_if) - ($ext_if:0) - Note that if you had set a skip on enc0, you should remove it and use something like pass quick on enc0 for the nat to be applied. It works for me, local addresses are nated inside the tunnel and cannot be seen by the remote servers. Feel free to ask if you need more details. Cheers, William 2008/8/15 Marc-Andre Jutras [EMAIL PROTECTED]: Hey List ! ... Interesting... I was about to send an e-mail on the list regarding this same question : aka: Best practice on NAT over IPsec... or how to do it correctly ?!?!?!? May I can suggest you to try something... : ( that what I will try anyway somewhere next week or so... ) Create a Loopback interface on one of your BSD and try to NAT on this 'lo' interface ... from that nat, adjust your pf to block all from lan A to lab B except from NAT ...and well, I think it should work ! any other suggestion to try or any ''already working here' ' notes that someone can post ? Regards, M-A Jorge Valbuena wrote: I have the following configuration: LAN_B--[openBSD+Pf+Nat+VPN]---(internet)---[OpenBSD+Pf+NAT+VPN]---[openBSD+Squid]---LAN_A http://bsdsupport.org/ , setting up Ipsec over GRE on OpenBSD I can ping a host from LAN_A to a host on LAN_B I hope this can Help ! Original-Nachricht Datum: Wed, 13 Aug 2008 16:41:20 -0400 Von: Toby Burress [EMAIL PROTECTED] An: misc@openbsd.org Betreff: Using PF to NAT internal addresses over an IPSec link I have an IPSec connection set up to an external site, over which I have no control and whose topololgy I know nothign about (i.e. I don't know what subnets they use, etc.) Using ipsecctl, I have one flow set up, from my external IP A.B.C.D to an internal IP on their side, 172.25.0.1. I can ping 172.25.0.1 from the OpenBSD box, so IPSec is working fine. What I want to do is allow any machine from my internal networks to reach 172.25.0.1. What I would like to do is set up NAT, so that packets headed to the OpenBSD box from anywhere on my network get translated to A.B.C.D, which is then sent over the VPN connection. Unfortunately it looks like PF only applies NAT transforms when packets leave interfaces, not when they enter them, so packets come into the OpenBSD box with their private IPs, get routed out the interface associated with the default route, and only then get rewritten. Is there a better way to do this? I would like to be able to change which hosts on my side can go over the IPSec connection without having to coordinate with the other company, and without having to expose internal IP information. If you reply to the list please cc me as I am not subscribed.
Using PF to NAT internal addresses over an IPSec link
I have an IPSec connection set up to an external site, over which I have no control and whose topololgy I know nothign about (i.e. I don't know what subnets they use, etc.) Using ipsecctl, I have one flow set up, from my external IP A.B.C.D to an internal IP on their side, 172.25.0.1. I can ping 172.25.0.1 from the OpenBSD box, so IPSec is working fine. What I want to do is allow any machine from my internal networks to reach 172.25.0.1. What I would like to do is set up NAT, so that packets headed to the OpenBSD box from anywhere on my network get translated to A.B.C.D, which is then sent over the VPN connection. Unfortunately it looks like PF only applies NAT transforms when packets leave interfaces, not when they enter them, so packets come into the OpenBSD box with their private IPs, get routed out the interface associated with the default route, and only then get rewritten. Is there a better way to do this? I would like to be able to change which hosts on my side can go over the IPSec connection without having to coordinate with the other company, and without having to expose internal IP information. If you reply to the list please cc me as I am not subscribed.
PF/rdr/nat
Hi all, I was looking for any idea how to tune OBSD with PF, rdr nat. I use rdr round-robin of port 80 to backend webservers using private adress space. When packets go back to clients watching webpage PF makes nat on them. Anyway, if I check it with ~100Mbps of traffic everything goes slower and slower and after few minutes clients sees that webserver is responding with very long delay to client's requests. However after ~15 seconds everything works well for another minute... I was reading OpenBSD/PF FAQ, trying to change limits in PF but problem still exists. After pfctl -x misc the following comes to logs: Nov 16 08:06:30 ungabunga /bsd: pf: BAD state: TCP 10.0.0.1:80 1.1.1.1:80 2.2.2.23:5027 [lo=1659423809 high=1659488734 win=16384 modulator=0] [lo=1312540182 high=1312540506 win=65535 modulator=0] 4:4 A seq=1312540182 ack=1659423809 len=1460 ackskew=0 pkts=3188:5511 dir=out,rev Doest anyone have an idea what I should look for to find what should be tuned up? other info: there are ~2500 state entries. TIMEOUTS: tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s udp.first60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 15s interval 10s adaptive.start24000 states adaptive.end 48000 states src.track 0s LIMITS: stateshard limit4 src-nodes hard limit4 frags hard limit4 tableshard limit 1000 table-entries hard limit 10 -- regards, Sylwester S. Biernacki [EMAIL PROTECTED] X-NET, http://www.xnet.com.pl/
Re: PF/rdr/nat
Send us a dmesg. How much memory does the box have? If it will legitimately serve that much traffic, try lowering the Apache timeouts to lower than the default (iirc 60 seconds?). Then match those timeouts to pf. Are you using source-hash in the config? That will create a state table of already established connections, to bypass cpu-intensive lookups when existing connection state sources send more packets. I think you're on the right track with timeouts, and a little bit of tuning should do the trick. If nothing you do is able to mitigate the slowdowns, consider using carp to load-balance the traffic. A couple other things to check which may or may not help: logs for system errors, ethernet interface stats (errors etc), MTU size, ethernet cable length, free memory stats, other running processes, upgrading to the latest version of OpenBSD - I don't know what version you are running, and the webserver itself which out of scope for OpenBSD problems :) Have a great day, Pierre Sylwester S. Biernacki wrote: Hi all, I was looking for any idea how to tune OBSD with PF, rdr nat. I use rdr round-robin of port 80 to backend webservers using private adress space. When packets go back to clients watching webpage PF makes nat on them. Anyway, if I check it with ~100Mbps of traffic everything goes slower and slower and after few minutes clients sees that webserver is responding with very long delay to client's requests. However after ~15 seconds everything works well for another minute... I was reading OpenBSD/PF FAQ, trying to change limits in PF but problem still exists. After pfctl -x misc the following comes to logs: Nov 16 08:06:30 ungabunga /bsd: pf: BAD state: TCP 10.0.0.1:80 1.1.1.1:80 2.2.2.23:5027 [lo=1659423809 high=1659488734 win=16384 modulator=0] [lo=1312540182 high=1312540506 win=65535 modulator=0] 4:4 A seq=1312540182 ack=1659423809 len=1460 ackskew=0 pkts=3188:5511 dir=out,rev Doest anyone have an idea what I should look for to find what should be tuned up? other info: there are ~2500 state entries. TIMEOUTS: tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s udp.first60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 15s interval 10s adaptive.start24000 states adaptive.end 48000 states src.track 0s LIMITS: stateshard limit4 src-nodes hard limit4 frags hard limit4 tableshard limit 1000 table-entries hard limit 10
Re: pf isakmpd: NAT through encryption interface?
On Wed, 28 Jun 2006, Stephen Bosch wrote: Hi, Roy: Roy Morris wrote: Yes it does work! I guess I better hold on to these two boxes I have. Seems they are the only ones that do! lol I have A. clients on each end behind a vpn/pf box B. enc0 binat from internal client to public IP of other side client C. /etc/hostname.if alias for the binat IP D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat) for phase 2 I've had a closer look at this... In my case, the other peer expects a private IP on my internal network. Your directions involve an alias. Do I need this alias? Can I not just nat on the encryption interface like so? nat on $enc_if from $internal_ip to $remote_internal_ip - $private_nat_address? This is really confusing me. -Stephen- If you do nat on $enc_if your incoming packets will not match an existing IPSEC flow and will never get routed to your enc0 interface in the first place. man ipsec shows a flow diagram of how packets move in the kernel -Matt-
Re: pf isakmpd: NAT through encryption interface?
Hi, Roy: Roy Morris wrote: Yes it does work! I guess I better hold on to these two boxes I have. Seems they are the only ones that do! lol I have A. clients on each end behind a vpn/pf box B. enc0 binat from internal client to public IP of other side client C. /etc/hostname.if alias for the binat IP D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat) for phase 2 I've had a closer look at this... In my case, the other peer expects a private IP on my internal network. Your directions involve an alias. Do I need this alias? Can I not just nat on the encryption interface like so? nat on $enc_if from $internal_ip to $remote_internal_ip - $private_nat_address? This is really confusing me. -Stephen- Have you actually tried it? nat on enc0 from $ip_to_be_changed to $peer_net - $nat_ip
pf isakmpd: NAT through encryption interface?
Imagine the following scenario: You have two VPN endpoints. One is an OpenBSD system running isakmpd and pf, the other is a VPN concentrator from some vendor. The OpenBSD already has other VPNs set up, all using the same internal network. Renumbering isn't going to work. The VPN concentrator operator has an internal addressing scheme he insists other endpoints conform to. The question, then: Is it even possible to NAT through an encryption interface? For example: OpenBSD internal network: 192.168.45.0/24 Network other guy would prefer OpenBSD use: 10.110.40.0/24 Network other guy is using: 10.110.10.0/24 The command might look like this: nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network - 10.110.40.10 Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of the command is wrong. I'd rather run it past the list than tinker on production equipment. Thanks for any help and advice, -Stephen-
Re: pf isakmpd: NAT through encryption interface?
Stephen Bosch wrote: Imagine the following scenario: You have two VPN endpoints. One is an OpenBSD system running isakmpd and pf, the other is a VPN concentrator from some vendor. The OpenBSD already has other VPNs set up, all using the same internal network. Renumbering isn't going to work. The VPN concentrator operator has an internal addressing scheme he insists other endpoints conform to. The question, then: Is it even possible to NAT through an encryption interface? For example: OpenBSD internal network: 192.168.45.0/24 Network other guy would prefer OpenBSD use: 10.110.40.0/24 Network other guy is using: 10.110.10.0/24 The command might look like this: nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network - 10.110.40.10 Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of the command is wrong. I'd rather run it past the list than tinker on production equipment. Thanks for any help and advice, -Stephen- blind leading the blind here but This was recently discussed, and it was pointed out that the decision to encrypt happens before the nat-ing. I deal with this self same issue by the lazy expedient of a firewall with a vpn server that has one interface in the dmz and one on the public net. So I do the vendor mandated nat-ing and pass to the vpn server. This made writing the pf rules for both sets of machines pretty straight forward.
Re: pf isakmpd: NAT through encryption interface?
Dag Richards wrote: Stephen Bosch wrote: Imagine the following scenario: You have two VPN endpoints. One is an OpenBSD system running isakmpd and pf, the other is a VPN concentrator from some vendor. The OpenBSD already has other VPNs set up, all using the same internal network. Renumbering isn't going to work. The VPN concentrator operator has an internal addressing scheme he insists other endpoints conform to. The question, then: Is it even possible to NAT through an encryption interface? For example: OpenBSD internal network: 192.168.45.0/24 Network other guy would prefer OpenBSD use: 10.110.40.0/24 Network other guy is using: 10.110.10.0/24 The command might look like this: nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network - 10.110.40.10 Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of the command is wrong. I'd rather run it past the list than tinker on production equipment. Thanks for any help and advice, -Stephen- blind leading the blind here but This was recently discussed, and it was pointed out that the decision to encrypt happens before the nat-ing. Correct me if I am wrong, then -- this should work. I should be able to set up a NAT rule that will affect encrypted traffic in the way I want. Someone mentioned to me that this does work in 3.9. Will it work in 3.8? That's what our gear is running. -Stephen-
Re: pf isakmpd: NAT through encryption interface?
Stephen Bosch wrote: Dag Richards wrote: Stephen Bosch wrote: Imagine the following scenario: You have two VPN endpoints. One is an OpenBSD system running isakmpd and pf, the other is a VPN concentrator from some vendor. The OpenBSD already has other VPNs set up, all using the same internal network. Renumbering isn't going to work. The VPN concentrator operator has an internal addressing scheme he insists other endpoints conform to. The question, then: Is it even possible to NAT through an encryption interface? For example: OpenBSD internal network: 192.168.45.0/24 Network other guy would prefer OpenBSD use: 10.110.40.0/24 Network other guy is using: 10.110.10.0/24 The command might look like this: nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network - 10.110.40.10 Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of the command is wrong. I'd rather run it past the list than tinker on production equipment. Thanks for any help and advice, -Stephen- blind leading the blind here but This was recently discussed, and it was pointed out that the decision to encrypt happens before the nat-ing. Correct me if I am wrong, then -- this should work. I should be able to set up a NAT rule that will affect encrypted traffic in the way I want. Someone mentioned to me that this does work in 3.9. Will it work in 3.8? That's what our gear is running. -Stephen- Um no, it wont work. Once the traffic is encrypted you will no longer be able to nat it. The original packet is now and encrypted blob that is the payload of a new packet with a source of your gateway and dest their GW. you can nat the wrapper packet but not the payload. I have 2x ibm x series somethings for fw's, and 2x hp dl360s for vpn servers all running 3.9.
Re: pf isakmpd: NAT through encryption interface?
Stephen Bosch wrote: Dag Richards wrote: Stephen Bosch wrote: Imagine the following scenario: You have two VPN endpoints. One is an OpenBSD system running isakmpd and pf, the other is a VPN concentrator from some vendor. The OpenBSD already has other VPNs set up, all using the same internal network. Renumbering isn't going to work. The VPN concentrator operator has an internal addressing scheme he insists other endpoints conform to. The question, then: Is it even possible to NAT through an encryption interface? For example: OpenBSD internal network: 192.168.45.0/24 Network other guy would prefer OpenBSD use: 10.110.40.0/24 Network other guy is using: 10.110.10.0/24 The command might look like this: nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network - 10.110.40.10 Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of the command is wrong. I'd rather run it past the list than tinker on production equipment. Thanks for any help and advice, -Stephen- blind leading the blind here but This was recently discussed, and it was pointed out that the decision to encrypt happens before the nat-ing. Correct me if I am wrong, then -- this should work. I should be able to set up a NAT rule that will affect encrypted traffic in the way I want. Someone mentioned to me that this does work in 3.9. Will it work in 3.8? That's what our gear is running. -Stephen- Um no, it wont work. Once the traffic is encrypted you will no longer be able to nat it. The original packet is now and encrypted blob that is the payload of a new packet with a source of your gateway and dest their GW. you can nat the wrapper packet but not the payload. I have 2x ibm x series somethings for fw's, and 2x hp dl360s for vpn servers all running 3.9. Yes it does work! I guess I better hold on to these two boxes I have. Seems they are the only ones that do! lol I have A. clients on each end behind a vpn/pf box B. enc0 binat from internal client to public IP of other side client C. /etc/hostname.if alias for the binat IP D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat) for phase 2 (ip's changed to protect the innocent. No animals were harmed during this test) Jun 28 13:23:32.881298 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 111.111.111.111: 222.222.222.222.25247 111.111.111.222.80: S [tcp sum ok] 789729009:789729009(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 345218535 0 (DF) [tos 0x10] (ttl 63, id 29296, len 64) (DF) [tos 0x10] (ttl 63, id 44546, len 84) Jun 28 13:23:32.882822 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 222.222.222.111: 111.111.111.222.80 222.222.222.222.25247: S [tcp sum ok] 3946347346:3946347346(0) ack 789729010 win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1861954054 345218535 (DF) (ttl 63, id 35574, len 64) (DF) (ttl 64, id 12842, len 84, bad cksum 0!) Jun 28 13:23:32.883716 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 111.111.111.111: 222.222.222.222.25247 111.111.111.222.80: . [tcp sum ok] ack 1 win 17376 nop,nop,timestamp 345218535 1861954054 (DF) [tos 0x10] (ttl 63, id 31269, len 52) (DF) [tos 0x10] (ttl 63, id 34993, len 72) Jun 28 13:23:37.013444 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 111.111.111.111: 222.222.222.222.25247 111.111.111.222.80: F [tcp sum ok] 1:1(0) ack 1 win 17376 nop,nop,timestamp 345218543 1861954054 (DF) [tos 0x10] (ttl 63, id 30180, len 52) (DF) [tos 0x10] (ttl 63, id 61997, len 72) Jun 28 13:23:37.013716 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 222.222.222.111: 111.111.111.222.80 222.222.222.222.25247: . [tcp sum ok] ack 2 win 17376 nop,nop,timestamp 1861954062 345218543 (DF) (ttl 63, id 56710, len 52) (DF) (ttl 64, id 21978, len 72, bad cksum 0!) Jun 28 13:23:37.013806 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 222.222.222.111: 111.111.111.222.80 222.222.222.222.25247: F [tcp sum ok] 1:1(0) ack 2 win 17376 nop,nop,timestamp 1861954062 345218543 (DF) (ttl 63, id 40038, len 52) (DF) (ttl 64, id 19310, len 72, bad cksum 0!) Jun 28 13:23:37.014441 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 111.111.111.111: 222.222.222.222.25247 111.111.111.222.80: . [tcp sum ok] ack 2 win 17375 nop,nop,timestamp 345218543 1861954062 (DF) [tos 0x10] (ttl 63, id 838, len 52) (DF) [tos 0x10] (ttl 63, id 53227, len 72) Jun 28 13:23:38.749637 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 111.111.111.111: 222.222.222.222.40612 111.111.111.222.80: S [tcp sum ok] 402874189:402874189(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 345218547 0 (DF) [tos 0x10] (ttl 63, id 9220, len 64) (DF) [tos 0x10] (ttl 63, id 51268, len 84) Jun 28 13:23:38.749953 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111
Re: pf isakmpd: NAT through encryption interface?
Roy Morris wrote: Stephen Bosch wrote: Dag Richards wrote: Stephen Bosch wrote: Imagine the following scenario: You have two VPN endpoints. One is an OpenBSD system running isakmpd and pf, the other is a VPN concentrator from some vendor. The OpenBSD already has other VPNs set up, all using the same internal network. Renumbering isn't going to work. The VPN concentrator operator has an internal addressing scheme he insists other endpoints conform to. The question, then: Is it even possible to NAT through an encryption interface? For example: OpenBSD internal network: 192.168.45.0/24 Network other guy would prefer OpenBSD use: 10.110.40.0/24 Network other guy is using: 10.110.10.0/24 The command might look like this: nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network - 10.110.40.10 Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of the command is wrong. I'd rather run it past the list than tinker on production equipment. Thanks for any help and advice, -Stephen- blind leading the blind here but This was recently discussed, and it was pointed out that the decision to encrypt happens before the nat-ing. Correct me if I am wrong, then -- this should work. I should be able to set up a NAT rule that will affect encrypted traffic in the way I want. Someone mentioned to me that this does work in 3.9. Will it work in 3.8? That's what our gear is running. -Stephen- Um no, it wont work. Once the traffic is encrypted you will no longer be able to nat it. The original packet is now and encrypted blob that is the payload of a new packet with a source of your gateway and dest their GW. you can nat the wrapper packet but not the payload. I have 2x ibm x series somethings for fw's, and 2x hp dl360s for vpn servers all running 3.9. Just for clarity, I made this diagram, so we are all talking about the same thing. http://www.openalternatives.com/oa-ipsec.png
Re: pf isakmpd: NAT through encryption interface?
Roy Morris wrote: Stephen Bosch wrote: Dag Richards wrote: Stephen Bosch wrote: Imagine the following scenario: You have two VPN endpoints. One is an OpenBSD system running isakmpd and pf, the other is a VPN concentrator from some vendor. The OpenBSD already has other VPNs set up, all using the same internal network. Renumbering isn't going to work. The VPN concentrator operator has an internal addressing scheme he insists other endpoints conform to. The question, then: Is it even possible to NAT through an encryption interface? For example: OpenBSD internal network: 192.168.45.0/24 Network other guy would prefer OpenBSD use: 10.110.40.0/24 Network other guy is using: 10.110.10.0/24 The command might look like this: nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network - 10.110.40.10 Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of the command is wrong. I'd rather run it past the list than tinker on production equipment. Thanks for any help and advice, -Stephen- blind leading the blind here but This was recently discussed, and it was pointed out that the decision to encrypt happens before the nat-ing. Correct me if I am wrong, then -- this should work. I should be able to set up a NAT rule that will affect encrypted traffic in the way I want. Someone mentioned to me that this does work in 3.9. Will it work in 3.8? That's what our gear is running. -Stephen- Um no, it wont work. Once the traffic is encrypted you will no longer be able to nat it. The original packet is now and encrypted blob that is the payload of a new packet with a source of your gateway and dest their GW. you can nat the wrapper packet but not the payload. I have 2x ibm x series somethings for fw's, and 2x hp dl360s for vpn servers all running 3.9. Yes it does work! I guess I better hold on to these two boxes I have. Seems they are the only ones that do! lol I have A. clients on each end behind a vpn/pf box B. enc0 binat from internal client to public IP of other side client C. /etc/hostname.if alias for the binat IP D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat) for phase 2 (ip's changed to protect the innocent. No animals were harmed during this test) Jun 28 13:23:32.881298 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 111.111.111.111: 222.222.222.222.25247 111.111.111.222.80: S [tcp sum ok] 789729009:789729009(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 345218535 0 (DF) [tos 0x10] (ttl 63, id 29296, len 64) (DF) [tos 0x10] (ttl 63, id 44546, len 84) Jun 28 13:23:32.882822 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 222.222.222.111: 111.111.111.222.80 222.222.222.222.25247: S [tcp sum ok] 3946347346:3946347346(0) ack 789729010 win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1861954054 345218535 (DF) (ttl 63, id 35574, len 64) (DF) (ttl 64, id 12842, len 84, bad cksum 0!) Jun 28 13:23:32.883716 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 111.111.111.111: 222.222.222.222.25247 111.111.111.222.80: . [tcp sum ok] ack 1 win 17376 nop,nop,timestamp 345218535 1861954054 (DF) [tos 0x10] (ttl 63, id 31269, len 52) (DF) [tos 0x10] (ttl 63, id 34993, len 72) Jun 28 13:23:37.013444 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 111.111.111.111: 222.222.222.222.25247 111.111.111.222.80: F [tcp sum ok] 1:1(0) ack 1 win 17376 nop,nop,timestamp 345218543 1861954054 (DF) [tos 0x10] (ttl 63, id 30180, len 52) (DF) [tos 0x10] (ttl 63, id 61997, len 72) Jun 28 13:23:37.013716 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 222.222.222.111: 111.111.111.222.80 222.222.222.222.25247: . [tcp sum ok] ack 2 win 17376 nop,nop,timestamp 1861954062 345218543 (DF) (ttl 63, id 56710, len 52) (DF) (ttl 64, id 21978, len 72, bad cksum 0!) Jun 28 13:23:37.013806 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 222.222.222.111: 111.111.111.222.80 222.222.222.222.25247: F [tcp sum ok] 1:1(0) ack 2 win 17376 nop,nop,timestamp 1861954062 345218543 (DF) (ttl 63, id 40038, len 52) (DF) (ttl 64, id 19310, len 72, bad cksum 0!) Jun 28 13:23:37.014441 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 111.111.111.111: 222.222.222.222.25247 111.111.111.222.80: . [tcp sum ok] ack 2 win 17375 nop,nop,timestamp 345218543 1861954062 (DF) [tos 0x10] (ttl 63, id 838, len 52) (DF) [tos 0x10] (ttl 63, id 53227, len 72) Jun 28 13:23:38.749637 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 111.111.111.111: 222.222.222.222.40612 111.111.111.222.80: S [tcp sum ok] 402874189:402874189(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 345218547 0 (DF) [tos 0x10] (ttl 63, id 9220, len 64) (DF) [tos 0x10] (ttl 63, id 51268, len 84) Jun 28 13:23:38.749953 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 222.222.222.111: 111.111.111.222.80 222.222.222.222.40612: S [tcp
Re: pf isakmpd: NAT through encryption interface?
Dag Richards wrote: Um no, it wont work. Once the traffic is encrypted you will no longer be able to nat it. The original packet is now and encrypted blob that is the payload of a new packet with a source of your gateway and dest their GW. you can nat the wrapper packet but not the payload. Just a thought: how about building the tunnel for the nat-ed network only? In this case something along the lines of: ipsec.conf: flow esp from 10.110.40.0/24 to 10.110.10.0/24 peer $remote_gw [...] and pf.conf nat on $int_if from 192.168.45.0/24 to 10.110.10.0/24 - 10.110.40.0/24 source-hash [...] The packet would then have to be reinserted at a point before the encryption decision is made ... I'm not sure if this is possible at all ... if there's a way to redirect the packet to the internal interface again, as if it were just arriving, it should be, though ... krgds /markus
Re: pf isakmpd: NAT through encryption interface?
Hi, Roy: Roy Morris wrote: Yes it does work! I guess I better hold on to these two boxes I have. Seems they are the only ones that do! lol I have A. clients on each end behind a vpn/pf box B. enc0 binat from internal client to public IP of other side client C. /etc/hostname.if alias for the binat IP D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat) for phase 2 I've had a closer look at this... In my case, the other peer expects a private IP on my internal network. Your directions involve an alias. Do I need this alias? Can I not just nat on the encryption interface like so? nat on $enc_if from $internal_ip to $remote_internal_ip - $private_nat_address? This is really confusing me. -Stephen-
Re: pf isakmpd: NAT through encryption interface?
Roy Morris wrote: Stephen Bosch wrote: Dag Richards wrote: Um no, it wont work. Once the traffic is encrypted you will no longer be able to nat it. The original packet is now and encrypted blob that is the payload of a new packet with a source of your gateway and dest their GW. you can nat the wrapper packet but not the payload. I have 2x ibm x series somethings for fw's, and 2x hp dl360s for vpn servers all running 3.9. Yes it does work! I guess I better hold on to these two boxes I have. Seems they are the only ones that do! lol I have A. clients on each end behind a vpn/pf box B. enc0 binat from internal client to public IP of other side client C. /etc/hostname.if alias for the binat IP D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat) for phase 2 Just to be clear here, I'll try and explain in greater detail. I have a host with IP 10.225.10.10. The remote network is 10.40.10.0/24. The remote network insists that my internal host be on the 10.50.10.0/24 network. In a perfect world, I'd just renumber on my end, or get him to accept my internal network, but he won't do that. So I have to NAT my internal network to a private IP that fits his addressing scheme. I need to NAT 10.225.10.10 so that it will appear as 10.50.10.10 in the remote peer's tunnel. If NAT happens before encryption, then this should be possible. If NAT happens after encryption, I have a problem, and an alias doesn't look like it's going to help. Feedback? -Stephen-
Re: pf and nat question for $ext_if with 2 ip addresses
Melameth, Daniel D. wrote: Tor Houghton wrote: I have two IP addresses assigned to the external interface. I also have two internal interfaces. Is it possible to NAT each internal interface to a specific external IP address (without specifying the external address, but the interface description)? I am using 3.8; and in my mind I thought I could perhaps use something like nat on $ext_if from ($int1_if) to any - ($ext_if:0) nat on $ext_if from ($int2_if) to any - ($ext_if:1) You can do something like $int_if:network, but the :1 keyword does not exist and, thus, will need to specified. It's generally better to do this with macros if you're statically configured. That way you know that it's hardcoded and that macro is generally useful elsewhere in pf.conf ex: nat on $ext_if from ($int1_if:network) - $EXTERNAL1 Even if it would be possible to do :1 :2 :3, there's lots and lots of ways to get burned if you were to change the hostname.if file and suddenly all your IPs are in a different order. -- Joseph C. Bender jcbender at bendorius dot com
pf and nat question for $ext_if with 2 ip addresses
Hi, I have two IP addresses assigned to the external interface. I also have two internal interfaces. Is it possible to NAT each internal interface to a specific external IP address (without specifying the external address, but the interface description)? I am using 3.8; and in my mind I thought I could perhaps use something like nat on $ext_if from ($int1_if) to any - ($ext_if:0) nat on $ext_if from ($int2_if) to any - ($ext_if:1) If I specify the pool used on each interface and the actual addresses of $ext_if, it will work, e.g. nat on $ext_if 10.0.0.0 to any - ext.if.addr.primary nat on $ext_if 172.16.0.0 to any - ext.if.addr.alias Just wondering. Tor
Re: pf and nat question for $ext_if with 2 ip addresses
Tor Houghton wrote: I have two IP addresses assigned to the external interface. I also have two internal interfaces. Is it possible to NAT each internal interface to a specific external IP address (without specifying the external address, but the interface description)? I am using 3.8; and in my mind I thought I could perhaps use something like nat on $ext_if from ($int1_if) to any - ($ext_if:0) nat on $ext_if from ($int2_if) to any - ($ext_if:1) You can do something like $int_if:network, but the :1 keyword does not exist and, thus, will need to specified. If I specify the pool used on each interface and the actual addresses of $ext_if, it will work, e.g. nat on $ext_if 10.0.0.0 to any - ext.if.addr.primary nat on $ext_if 172.16.0.0 to any - ext.if.addr.alias Just wondering.
pf + wan nat loopback - possible?
I had all of this working with PPPoE + PF, but now i have a T-1 with several IPs all aliased off of the main. pf is working finehowever, I now have lost WAN NAT LOOPBACK. What I need is a way to go from one LAN machine to the WAN and loopback to the other LAN machine. LAN-WAN-LAN Since this 'just works' with pppoe, how do I do it with pf? simple pf.conf: binat on $bge1 from 192.168.82.170 to any - 67.x.x.1 binat on $bge1 from 192.168.82.171 to any - 67.x.x.2 binat on $bge1 from 192.168.82.172 to any - 67.x.x.3 binat on $bge1 from 192.168.82.173 to any - 67.x.x.4 and so on. I need to use 192.168.82.172 to go and connect to public 67.x.x.2 This results in an immediate connection refused. I see nothing in the pflog and I even tried pass out quick all. So I dont think pf is technically blocking it -but Why do I need this? - I run 2 external DNS servers (with views) and as such NS2 needs to talk to NS1 but using the WAN NAT loopbacks. thanks in advance for any tips. -- J.D. Bronson Information Services Aurora Health Care - Milwaukee, Wisconsin Office: 414.978.8282 // Fax: 414.977.5299 -Taco Bell is *not* the Mexican Telephone Company-
