Correction for the zones
zones
tstgw:net ipv4 #TST access gateway
tsgws:tstgw ipsec mode=tunnel mss=1400 #TST VPN
tssft:net ipv4
tssfp:tssft ipsec
On 8 Jun 2022, at 14:00, Ed Hunter <edhunt...@outlook.com> wrote:
Hi everyone,
I have a pretty complex setup on a debian server with a lot of moving parts,
quagga, shorewall and of course strongswan. I am using it as a gateway. This
was not set up by me but I’m administering it so bear with me.
I am trying to set up NAT for a VPN since our subnets are clashing. I must be
missing something along the way since i applied the changes i am going to post
here and i lost access to a lot of things internally.
Ill try to post everything relevant so that i give as much info as possible to
determine the correct way to do this as well as to be able to figure out what
might have been causing my issues when applying the changes.
I have a VPN that is already established with strongswan. This is the config (I
am omitting public IP for obvious reasons.)
conn ld4-csc
auto=start
type=tunnel
left=X.X.X.X
leftsubnet=10.70.66.0/24
leftid=X.X.X.X
leftauth=psk
right=Y.Y.Y.Y
rightsubnet=192.168.95.0/24
rightid=Y.Y.Y.Y
rightauth=psk
# authby=psk
keyexchange=ikev2
ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!
mobike=no
# rekey=no
# reauth=no
keyingtries=3
# margintime=9m
ikelifetime=24h
# rekeyfuzz=100%
lifetime=8h
# pfs=yes
dpddelay=100s
dpdtimeout=300s
dpdaction=restart
The endpoint that needs to be routed from my side is a server with IP
192.168.129.195. The endpoint on the other side of the VPN is 192.168.95.10/32
The other side informed us that the 192.168.129.0/24 subnet is already in use
and clashing on their side so that we NAT the IP on our side.
Please note that i am also using the whole 192.168.0.0/19 on my side for my
VLANS. (this is where i think my issue lies since their internal subnet that is
routed is 192.168.95.0/24)
Hence, i used 10.70.66.0/24, and i was looking for the correct way to NAT.
This is the config and the relevant files i applied for shorewall.
tunnels
ipsec net Y.Y.Y.Y tstgw
# TST Peer
hosts
tstgw eth1:Y.Y.Y.Y
#TST Gateway (Child Zone of net)
tsgws eth1:Y.Y.Y.Y ipsec #TST
Gateway (Over ipsec)
tssft eth1:192.168.95.0/24 #TST internal
tssfp eth1:192.168.95.0/24 ipsec #TST internal
zones
tstgw:net ipv4 #TST access gateway
tsgws:cscgw ipsec mode=tunnel mss=1400 #TST VPN
tssft:net ipv4
tssfp:cssft ipsec
policy
tssfp all CONTINUE
rules
Ping(ACCEPT):info corzn:192.168.129.195 tssft
Ping(ACCEPT):info tssft corzn:192.168.129.195
and the way i, well thought that it would work, tried to nat
masq
eth1:192.168.95.0/24 192.168.129.195/32 10.70.66.10
Now, as i mentioned, i have the whole 192.168.0.0/19 routed through some other
site-to-site vpns i have however i dont have the subnet 192.168.95.0/24
configured as a vlan/zone anywhere.
private/interfaces
sstun:- tun11 detect
routefilter=0,sfilter=(192.168.0.0/16,224.0.0.0/8)
sstun:- tun13 detect
routefilter=0,sfilter=(192.168.0.0/16,224.0.0.0/8)
I also have the whole 192.168.0.0/19 in my OSPF areas
quagga/ospfd.conf.sav:ip prefix-list EXITAREA1 seq 5 permit 192.168.0.0/16 ge
17 le 30
quagga/ospfd.conf:ip prefix-list EXITAREA1 seq 5 permit 192.168.0.0/16 ge 17 le
30
quagga/zebra.conf.sav:ip prefix-list EXITAREA1 seq 5 permit 192.168.0.0/16 le 30
quagga/zebra.conf:ip prefix-list EXITAREA1 seq 5 permit 192.168.0.0/16 le 30
When i apply the changes, i lose access to all internal resources.
Is the way im trying to NAT in the masq file correct?
Essentially i want to NAT traffic from 192.168.129.195 to have a source address
of 10.70.66.10.
I am running shorewall v 4.5.5.3
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
