Re: pf nat and routing question
> On 25 Jun 2015, at 15:46, Marko Cupać wrote: > > On Wed, 24 Jun 2015 08:17:15 -0400 > Michel Blais wrote: > >> The solution seem his explain on this link >> >> http://www.openbsd.org/faq/pf/rdr.html#reflect > > On Thu, 25 Jun 2015 14:50:42 +0100 > Andy Lemin wrote: > >> Hi, >> >> We do exactly the same thing for our wifi network. Users on wifi can >> *only* use public IP addresses. >> >> The solution is easy, you just have to consider where you do your >> nat'ing; > > Michel, Andy, > > thank you for your suggestions. > > I went for http://www.openbsd.org/faq/pf/rdr.html#tcpproxy > > I'm satisfied with result. Cool, but you are using a big hammer (not a sledge ;) for a nut.. And your CPU knows the difference. If load is v.small, then irelevant. > > Regards, > -- > Marko Cupać > https://www.mimar.rs/
Re: pf nat and routing question
On Wed, 24 Jun 2015 08:17:15 -0400 Michel Blais wrote: > The solution seem his explain on this link > > http://www.openbsd.org/faq/pf/rdr.html#reflect On Thu, 25 Jun 2015 14:50:42 +0100 Andy Lemin wrote: > Hi, > > We do exactly the same thing for our wifi network. Users on wifi can > *only* use public IP addresses. > > The solution is easy, you just have to consider where you do your > nat'ing; Michel, Andy, thank you for your suggestions. I went for http://www.openbsd.org/faq/pf/rdr.html#tcpproxy I'm satisfied with result. Regards, -- Marko Cupać https://www.mimar.rs/
Re: pf nat and routing question
Hi, We do exactly the same thing for our wifi network. Users on wifi can *only* use public IP addresses. The solution is easy, you just have to consider where you do your nat'ing; You can't do bin-at, so you will need nat-to and rdr-to rules to make it work. E.g. The following line translates the public IP to the internal IP regardless of whether to connection "ingresses" the firewall from the outside web, or from your internal wifi network match in proto tcp from any to { $ext_ip_rc5 } port { https } rdr-to $int_ip_lard But the nat-to is only needed on the outside interface match out on { $if_ext } from { $int_ip_lard } to any nat-to $ext_ip_rc5 And so you will need three rules.. Ingress pass rule on the external interface, another ingress pass rule on the wifi interface, and an egress pass rule on the DMZ interface where the server is. If the internal server is on the same LAN as the internal clients that *have to use the public IP address, then an extra nat-to rule is needed. Keep the same ingress rdr-to rule to translate the public to the private, but you will also need an extra nat-to rule as the packet egresses the firewall to make all connection look like they have come from the firewall. This ensure that when the server replies, it replies back to the firewall, who then replies back to the internal client. Without this rule the internal server would just reply to the internal client directly, meaning the firewall only sees the forward traffic and won't be able to update its states properly and things won't work. PS; Make sure to be carful about what internal firewall IP you NAT to, and you need to remember that this limits the number of connections to the internal server, as everyone (from internal) will appear to come from the firewall which has a limited number of source ports... EG; This ensure that if a firewall failover happens (with CARP) that all still works :) pass out on $if_lan from ($if_lan:network) to $server nat-to (carp1) Hope this helps. A > On 24 Jun 2015, at 12:16, Marko CupaÄ wrote: > > Hi, > > my setup is actually more complicated, but for purpose of this mail I > am going to try and keep it simple. > > My firewall redirects requests to some service from the Internet to > server on private network: > > pass in on $ext_if inet proto tcp from any to $srv-pub port $service rdr-to $srv-priv > > Internet hosts can access service without problem via its public IP > address. > > Clients on internal network can access service without problem via its > private IP address. > > Now, I have some clients on internal network who are forbidden > communication with private address space, so they need to access > service via its public IP address. Unfortunately this does not work. > > Hopefully someone already had this problem and will be able to point me > in the right direction. > > Regards, > -- > Marko CupaÄ > https://www.mimar.rs/
Re: pf nat and routing question
The solution seem his explain on this link http://www.openbsd.org/faq/pf/rdr.html#reflect Message d'origine De: Marko Cupać Envoyé: mercredi 24 juin 2015 07:21 À: misc@openbsd.org Objet: pf nat and routing question Hi, my setup is actually more complicated, but for purpose of this mail I am going to try and keep it simple. My firewall redirects requests to some service from the Internet to server on private network: pass in on $ext_if inet proto tcp from any to $srv-pub port $service rdr-to $srv-priv Internet hosts can access service without problem via its public IP address. Clients on internal network can access service without problem via its private IP address. Now, I have some clients on internal network who are forbidden communication with private address space, so they need to access service via its public IP address. Unfortunately this does not work. Hopefully someone already had this problem and will be able to point me in the right direction. Regards, -- Marko Cupać https://www.mimar.rs/
pf nat and routing question
Hi, my setup is actually more complicated, but for purpose of this mail I am going to try and keep it simple. My firewall redirects requests to some service from the Internet to server on private network: pass in on $ext_if inet proto tcp from any to $srv-pub port $service rdr-to $srv-priv Internet hosts can access service without problem via its public IP address. Clients on internal network can access service without problem via its private IP address. Now, I have some clients on internal network who are forbidden communication with private address space, so they need to access service via its public IP address. Unfortunately this does not work. Hopefully someone already had this problem and will be able to point me in the right direction. Regards, -- Marko Cupać https://www.mimar.rs/