You can masquerade many local networks against your external interface. I have my Internal, DMZ and PPTP-POOL networks individually masqueraded against the External interface. This works fine.
a) you can snat a whole network against a single IP if you wish (for example, a DMZ network, or a subset of a network against a different IP on the external interface.
b) masquerading is assigned to an interface, not an ip. it is designed (IIRC) for people doing dialup who may not know the ip that is going to be assigned to an interface (dhcp from the isp), but need to hide an rfc1918 address space behind that interface none-the-less. it will pickup the first/main address on the interface.
the fact that astaro does not allow you to pick a different address to masq through is down to the way iptables works, not through any lack of functionality in asl. if you *need* to do the equiv of
I have 2 LANS (ex. 192.168.0.0/24 and 192.168.1.0/24). Now I have Masquerading for both LANS on external NIC with one public IP. All I need is Masquerading the first LAN 192.168.0.0/24 --> 212.160.xxx.1 and the second LAN 192.168.1.0/24 --> 212.160.xxx.2 (additional address of external NIC)
Now I see, to do this, all I need is the second external NIC [:(]ht?
I have 2 LANS (ex. 192.168.0.0/24 and 192.168.1.0/24). Now I have Masquerading for both LANS on external NIC with one public IP. All I need is Masquerading the first LAN 192.168.0.0/24 --> 212.160.xxx.1 and the second LAN 192.168.1.0/24 --> 212.160.xxx.2 (additional address of external NIC)
Now I see, to do this, all I need is the second external NIC [:(]ht?
i would try to use 192.168.1.0 /24 and 192.168.2.0/24 (up to 192.168.254.0/24 if you want)
i guess 192.168.0.0 means 192.168.0.0/16
so you will run into the ip-spoofing-trouble! meaning all 192.168.1.x adresses are part of 192.168.0.0 and access is interpreted as ip-spoofing (because not coming from 192.168.0.0-nic). with this blocking masq won't work - i think. have a look in the kernel-log!
[ QUOTE ] ii guess 192.168.0.0 means 192.168.0.0/16
[/ QUOTE ] The 192.168.xx.xx address range is 256 consecutive class "C" networks. 192.168.0.0 is simply the first one of these, and on a classfull routing basis would default to a 24 bit netmask, not a 16 bit one.
I do not understand why so many people still think that using 192.168.0.xx, 192.168.1.xx or 192.168.2.xx is such a good choice for a private subnet. These are the very same numbers that everyone else is using, so they are most likely to give you address conflict problems when you try to run a VPN between your net and sombody else's private net. With all the class "C" subnets up to 192.168.255.xx available to you, you will do better if you pick a number higher than 0, 1 or 2 for the third address byte.
mainly because most enterprises use the 10.x private subnet and you would have hte same ip conflicts if you used the 10.x private range....i use the 192.168.0.x range here without problems both in regular usage and vpn when i need to use it.
[ QUOTE ] mainly because most enterprises use the 10.x private subnet and you would have hte same ip conflicts if you used the 10.x private range....
[/ QUOTE ]You are missing the point. I didn't question why someone would use a 192.168.xx.xx subnet, I questioned why they would use the 192.168.0.XX subnet (or the 192.168.1.xx net).
[ QUOTE ] use the 192.168.0.x range here without problems both in regular usage and vpn when i need to use it.
[/ QUOTE ]That only works as long as you don't try to route a VPN to another location that also uses 192.168.0.xx.
The point I was trying to make, is that with 256 class "C" subnets to chose from in the 192.168. address range, and with 65535 class "C" subnets to choose from in the 10. address range, why not pick a number for your private network other than the bottom number in each range? By picking a more exotic net number, you can avoid potential IP address range conflict that might appear when you open up VPN routing tunnels between networks that are on RFC 1918 compliant private address ranges.
As an example, if you choose, say, 192.168.197.00 as your private subnet, you'll never experience the problems that two sites, that both are using 192.168.0.0 as their subnet, are having when they try to open VPN routing tunnel between them.
Since so many inexperienced people, who know just enough about IP subnetting to be dangerous, will invariably use 192.168.0.0 as their subnet, and since most of the little 4-port routers made by Linksys, Netgear, SMc, etc. uses 192.168.1.0 or 192.168.2.0 as their factory default internal net, you are always better off by picking a number between 5 and 255 for the third octet when establishing a 192.168. subnet. That gives you 250 choices, reducing the odds of the 192.168. private range subnet number that you implement also being used in the other end of the VPN link down to 0.4%.
Personally, my home LAN uses 192.168.99.0, and my DMZ uses 192.168.90.0. I stay away from using single digit numbers in the third octet of a 192.168. class "C" network.
Thank you VelvetFog. It's good practical suggestion to don't use single digit numbers in the third octet of a 192.168. class "C" network when it's intended to use VPN
