dyn. SNAT based on different source addresses?

dyn. SNAT based on different source addresses?

[Meike Stone]

Hello,

we have a lot windows terminal server (TS) and want to access from
that TS to a file server behind a firewall, only NAT is possible. The
problem is that the smb protocol is not NAT compatible:
(msdn.microsoft.com/en-us/library/ee441661.aspx)

Simplified NAT (SNAT/DNAT) scenario I used is:

[192.168.1.0/24] - > Network wit TS
[192.168.2.0/24] - > Network, where the file server is located

192.168.2.142 => Fileserver
192.168.1.20   => "DNAT-IP" für Fileserver

All packages from the TSs in 192.168.1.0/24 will be translated in the src IP
192.168.2.222 (SNAT). TSs are connecting to 192.168.1.20 (DNAT) to
open a smb-session.

iptables -t nat -A POSTROUTING -o eth0 --dst 192.168.2.142 -j SNAT
--to-source 192.168.2.222
iptables -t nat -A PREROUTING -i eth1 --dst 192.168.1.20 -p tcp
--dport 139 -j DNAT --to-destination 192.168.2.142
iptables -A FORWARD -i eth1 -o eth0 -s 192.168.1.0/24 -d 192.168.2.142
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -s 192.168.2.142 -d 192.168.1.0/24
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A OUTPUT -o eth1 --dst 192.168.1.20 -j ACCEPT

That works fine, but with the described problem, connections are lost
because of imperfection in the smb protocol.


I'm looking for a solution, that each new connection  (to
192.168.1.20) from a different terminal server gets a new (SNAT)
address from a configured dynmaic pool in 192.168.2.0.


Using NETMAP, is a possible solution, following example works for me,
but is it not dynamic, all IP addresses are mapped 1:1

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A PREROUTING -i eth1 --dst 192.168.1.20 -p tcp
--dport 139 -j DNAT --to-destination 192.168.2.142
iptables -A FORWARD -i eth1 -o eth0 -s 192.168.1.0/24 -d 192.168.2.142
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -s 192.168.2.142 -d 192.168.1.0/24
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A OUTPUT -o eth1 --dst 192.168.1.20 -j ACCEPT

If terminal servers are not located in 192.168.1.0 but in different
networks connected via router,
I have a problem ....

Does anyone have a clue?

Thanks Meike

Re: dyn. SNAT based on different source addresses?

[Eliezer Croitoru]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am still unsure why do you need the complications?
A basic masquerade rule should be good enough to work with a fileserver.
Maybe you are having other settings wrong.
You can use a routing rule to use a specific device with specific IP
for a specific src.
iptables do not really supports dynamic NAT rules by default.

Eliezer

On 10/07/2014 09:27 PM, Meike Stone wrote:
> If terminal servers are not located in 192.168.1.0 but in
> different networks connected via router, I have a problem ....
> 
> Does anyone have a clue?
> 
> Thanks Meike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUNEWKAAoJENxnfXtQ8ZQU8FsIAITvleIR4VJzB4WQZkmZSEcf
f5Yi1LvH+SR8xDdApDmO5VYXVclpWGPO+4WhlqVhVAyFxkSGes8PfwnTBvc8XmPH
mdk6xruSTi0XzfeNm+t5HfMeeTWn1xxfu8CyU9PHpJptXTAeJ0qpVNSoRGbpL+Tm
/+hFh9ufXJzq4dVVOLi/lFHQPr1EJ8weBIeejRu4hOBzEvSv0b+we+aHpc9tYQX0
lFVyqiQyz1C/wF41gwVxUn5AalnHjjqms7Flz5Ut1h3HRmPNXcpEJ8vbGEH1BxIJ
AIO4MsC7J1Y4GwDOlJsJKvyiyB18QjiDeoNkE8IBHCMsOZ30xQKa75/3lT40mBk=
=VFzh
-----END PGP SIGNATURE-----

Re: dyn. SNAT based on different source addresses?

[Meike Stone]

> I am still unsure why do you need the complications?
> A basic masquerade rule should be good enough to work with a fileserver.

Yes and No, SMB does work over NAT but NOT for more than ONE Client.
The reason is described in the link I gave
(msdn.microsoft.com/en-us/library/ee441661.aspx)
There are two possibilities.
- Clients counts VC from 1 instead 0
- Server ignores "special meaning -> reseting) of VC=0

If Fileserver = samba, the you have the option to disable reseting on VC=0
(reset on zero vc, default disabled) On Windows server does not exist
such option.
=> .. or read man page for smb.conf and read "reset on zero vc"


For Clients, Microsoft brings for Windows 2008/Windows 7 and greater
a special patch, that
counts from VC from 1.

Now, over 100 Terminal Servers (w2k3) must use a fileserver in a other
company ....
Update all of them is no option in short time ...

> Maybe you are having other settings wrong.
No!

> You can use a routing rule to use a specific device with specific IP
> for a specific src.
I don't understand ...

> iptables do not really supports dynamic NAT rules by default.
that sounds, that there are hacks available?


Thanks Meike

Re: dyn. SNAT based on different source addresses?

[Neal Murphy]

Would a plain unencrypted GRE tunnel between the TS and the file server 
alleviate the problem? Or if data security is a concern, set up a proper VPN 
between them. And use iptables (and other firewalls as necessary) to limit 
traffic as desired whether it's a simple tunnel or a VPN. (You don't want the 
tunnel to be an easy bypass around the firewall.)


On Tuesday, October 07, 2014 06:15:05 PM Meike Stone wrote:
> > I am still unsure why do you need the complications?
> > A basic masquerade rule should be good enough to work with a fileserver.
> 
> Yes and No, SMB does work over NAT but NOT for more than ONE Client.
> The reason is described in the link I gave
> (msdn.microsoft.com/en-us/library/ee441661.aspx)
> There are two possibilities.
> - Clients counts VC from 1 instead 0
> - Server ignores "special meaning -> reseting) of VC=0
> 
> If Fileserver = samba, the you have the option to disable reseting on VC=0
> (reset on zero vc, default disabled) On Windows server does not exist
> such option.
> => .. or read man page for smb.conf and read "reset on zero vc"
> 
> 
> For Clients, Microsoft brings for Windows 2008/Windows 7 and greater
> a special patch, that
> counts from VC from 1.
> 
> Now, over 100 Terminal Servers (w2k3) must use a fileserver in a other
> company ....
> Update all of them is no option in short time ...
> 
> > Maybe you are having other settings wrong.
> 
> No!
> 
> > You can use a routing rule to use a specific device with specific IP
> > for a specific src.
> 
> I don't understand ...
> 
> > iptables do not really supports dynamic NAT rules by default.
> 
> that sounds, that there are hacks available?
> 
> 
> Thanks Meike
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dyn. SNAT based on different source addresses?

[Eliezer Croitoru]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/08/2014 01:27 AM, Neal Murphy wrote:
> Would a plain unencrypted GRE tunnel between the TS and the file
> server alleviate the problem? Or if data security is a concern, set
> up a proper VPN between them. And use iptables (and other firewalls
> as necessary) to limit traffic as desired whether it's a simple
> tunnel or a VPN. (You don't want the tunnel to be an easy bypass
> around the firewall.)
+1 on this.
Except a gre tunnel is not that easy on a Windows TS or at all on a
windows machine.
The main issue is that he has 200+ machines in one subnet that needs
access to the other one...

The options I now that works in windows are pptp(with internal GRE),
l2tp, openvpn and maybe couple others.

In this case the GW machine is a linux machine and can be used or
being used as the default gateway.
If it's the gateway it will be pretty simple to setup using a VPN but
he will need to address all sorts of details in the domain level(if used).

Eliezer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUNHcfAAoJENxnfXtQ8ZQU4FAIAJlItszd7wnPBKoLHq2qWOT6
1imYjfq33NIlOZETKCNkBep0bfKkqLvFUFdHe9uaChunXVBBbdDJF5FYqKmfm43X
qdD0m2pNfuy64cvGUwy58YycqtWCXarPgbMl/TGS4Xc0qx3MsZtgibwpkRMOTOiI
++8c7Km0xVzHuGv14WWXnKwSMs7O4nPg2/JXjKwP/FeK6zxuFJE2g/plqxOCOXDN
f/6HakMf+savsbkREORBXi6PVBSr30ByYn6BP1w9os0OwfsXJO2GYei1FnmZ8yot
aIXCIijmNNMrEShJPkX7heJaquGYZ/5NcWIM32ahl1F0imEjCICaq215mt9Nvho=
=qUpW
-----END PGP SIGNATURE-----

Re: dyn. SNAT based on different source addresses?

[Meike Stone]

> Except a gre tunnel is not that easy on a Windows TS or at all on a
> windows machine.
> The main issue is that he has 200+ machines in one subnet that needs
> access to the other one...

Not exactly, the terminal servers are located in different subnets in
one company, so NETMAP here is suboptimal  ....

>
> The options I now that works in windows are pptp(with internal GRE),
> l2tp, openvpn and maybe couple others.

Thanks for the ideas.
But tunnels are not an option. Admins on TS are running the strategy
"never change a running system", because the TS are fragile ...

Routing betwenn the two companies is not possible (overlapping ip
networks, different security policies, ..)
Thats is the reason for the DNAT rules ... The TSs access to the
fileserver over a IP in the own network.

Thought, I can solve the porblem with iptables ... iptables is so mighty ...

Thanks Meike

Re: dyn. SNAT based on different source addresses?

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/10/2014 8:01 p.m., Meike Stone wrote:
>> Except a gre tunnel is not that easy on a Windows TS or at all on
>> a windows machine. The main issue is that he has 200+ machines in
>> one subnet that needs access to the other one...
> 
> Not exactly, the terminal servers are located in different subnets
> in one company, so NETMAP here is suboptimal  ....
> 
>> 
>> The options I now that works in windows are pptp(with internal
>> GRE), l2tp, openvpn and maybe couple others.
> 
> Thanks for the ideas. But tunnels are not an option. Admins on TS
> are running the strategy "never change a running system", because
> the TS are fragile ...
> 
> Routing betwenn the two companies is not possible (overlapping ip 
> networks, different security policies, ..) Thats is the reason for
> the DNAT rules ... The TSs access to the fileserver over a IP in
> the own network.
> 
> Thought, I can solve the porblem with iptables ... iptables is so
> mighty ...

Have you considered implementing IPv6 on both of the networks? It is
designed to resolve just this type of problem set.

AYJ

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUNSZRAAoJELJo5wb/XPRjxF4H/j/bpGoiYZQ3q0H94qjuE+Rq
bJrAwXgHqDoSTSs8h0FzunFlVnDVh1ylDHNMmHhhVAI9RjZ18VdorwXrGieZqQuG
i3B0JNFyFj/AZUaNu6GlhPdkGNdAWFokFkcq2BGEOZ3E1XV3JoQ7+vrrZXBKY6vC
5bV8WRLnNa3fvWPP+wPcy32xDNAly6Jbo1uBYWIlROUcfXMfpsahXCxEQ/vTThMk
c86gtQ+KtEya2v/vr+HGetMwPxUdzCXUPmKk74gLwgNfK1aU+cN7NbvAxSBTh2BG
UqhnSmM5b7JlXDW6dZA09dmadl4gDQgLpVjFLobU7+kgM2ViSW6MUuEFd5aWKSc=
=Ntme
-----END PGP SIGNATURE-----