S-NAT through VPN (IPsec)
-
Hi there
i got the following setup:
+–----------+ +---------+
Net A ----| LAN | | |
| WAN |------()()Internet()()()----| |---- Net C
Net B ----| OPT | \ / | |
+------------+ ----- VPN Tunnel------/ +---------+The VPN is configured to have network A and network C as subnet-definitions, all three networks are private (192.168.X.0)
Now i also want to use Network C's services from Network B. since the remote firewall is a company firewall and i can't change my subnet on their side or bring up another tunnel i was using S-NAT on my old Astaro box.
SRC:netB DST:netC then change Source to a IP within NetA
since Astaro doesn't know about rules per-interface i just set up and that was working quite fine.
Now i changed to PFsense and i'm a bit confused.i set up the same rule in (advanced) outbound NAT, made sure it's the first one and added an Firewall rule (which works, see a pass-log).
first i was confused by what the connection state showed me. the connection was actually
[Host B] -> [WAN address] -> [Host C] and didn't work :)
so I played around with choosing other interfaces and using the Virtual IP:Interface: WAN
Source: Net B
Dest: Net C
Source Translate: VirtualIP from Net A (LAN Address of pfsense)that seems to be ok since i got the following state:
Host B:3657 -> VIP:3657 -> Host C:22 SYN_SENT:CLOSED
Host C:22 <- Host B:3657 CLOSED:SYN_SENTthat looks great, but i never recive another packet on the other side. and the state's are alway's SYN_SENT and CLOSED
what did i forgot? does anyone know what's first processed, VPN or NAT? i guess outgoing WAN interface is alright since there isn't a dedicated VPN interface to which i could apply this rule…?
cheers & thx
btw, im using pfsense 1.0.1 embedded.
-
As far as anybody knows, that doesn't work. You can't NAT prior to passing over IPsec.
-
Yeah, I don't think that is going to work. Might be able to do it with OpenVPN but I have not tried as of yet.
-
:(
na OpenVPN is no alternative since the other side wouldn't support this.
anyway. you guess that ipsec is processed before NAT? and there's no chance to change this? (astaro has a setting calles 'Strict Routing'. when this is disabled, playings like my setup is easy possible since ipsec is then the last processed part…after Nat, after several proxy's and other stuff.....)
so pfsense isn't a real alternative when stuff like this isn't possible. the old noisy astaro box will therefore be revived....
cheers & thanks
-
Yep, it's a kernel ordering issue between IPsec and NAT. IPsec happens first.
This is definitely something we want to support, just don't know of a way to easily do so at this time.
-
:)
would be great when this would work :)
i'm working with an ISP and i alway's have to deal with these !%&!/&ç*Qç+"*ç"ç&- Zyxel and Sonicwalls….and i was hoping that pfsense would be a good alternative :)hey thanks for the quick reply's
cheers
-
Just FYI. soved this issue with subnetting:
before:
Net A: 192.168.3.0/24
Net B: 192.168.4.0/24now:
Net A: 192.168.3.0/25
Net B: 192.168.3.128/25this way the VPN which goes to 192.168.3.0/24 covers both networks…a bit nasty, but works :)
cheers & thanks
-
Not nasty at all, I use one location as concentrator for 13 remote sites with the follwoing tunneldefinitions;
mainsite 192.168.0.0/16
remote site x 192.168.x.0/24The mainsite has a /24 as real lan as well. This way all sublocations can talk to each other being connected through mainlocation.
-
so Remotesite 192.168.11.0/24 can talk to 192.168.22.0/24? Through VPN to the mainsite and again VPN to the SiteB?
so btw…where would i have to apply PF filters for VPN tunnels? on the WAN side?
-
so Remotesite 192.168.11.0/24 can talk to 192.168.22.0/24? Through VPN to the mainsite and again VPN to the SiteB?
correct. All sublocations have only one Tunnel running to the mainsite but can talk to each other.
so btw…where would i have to apply PF filters for VPN tunnels? on the WAN side?
In recent snapshots you have filtering of incoming traffic through IPSEC. You'll find a tab at firewall>rules, IPSEC.
-
yeah. cool.
when my girlfriend is working this weekend, i'll upgrade :)
-
Not nasty at all
Yeah, NAT is the nasty solution, it breaks all kinds of stuff you would typically want to use across a corporate WAN. Using unique subnets at each remote location is just good network design, it's how virtually every well designed multi-site corporate network works.