04-11-2012 10:07 AM
I currently need to set up a DIP that performs source address translation on a policy basis which allows 500 clients to NAT to 500 individual IP's.
We need a one to one mapping but the one to one mapping does not need to be the same IP address all the time so does not require IP shifting.
I need the client to get an IP address from the DIP pool and keep that IP address for all concurrent sessions it then creates. Once the user logs off the machine I want the IP to go back to the DIP pool for another user to be able to use.
I have tried using DIP with fix-port which kind of works but after about 10 minutes the IP address changes for the client causing problems for my application I need to use the NAT for.
I believe I can resolve the issue by using set DIP sticky.
My issue is that I need to use set DIP sticky only on one DIP pool on my DMZ interface and not on a global basis.
I have DIP pools setup on my external interface that use port xlate and have multiple clients using one IP which I do not want to be affected by the set DIP sticky command.
I can not find on any of the documentation if it is possible to use the set DIP sticky on one DIP assigned to a specific interface and can only find how to enable the option globally.
Can anyone help with this at all please, any help will be greatly appreciated.
Solved! Go to Solution.
04-11-2012 04:56 PM
On the other hand, what is the downside to having global sticky DIP enabled in your case?
04-12-2012 02:08 AM
Thank you for your response. I am concerned that using sticky DIP globally will affect other DIPs that I have setup on other interfaces.
I am not sure how the setting will effect the other DIPs which are also setup on policy basis. The other DIPs are all port-xlate and have a range of 1 IP address. Do you have an idea on how this may effect the other DIPs at all? I am performing this on a production environment with other crucial applications using the variety of DIPs in place.
We have a strict change control policy in place and I need to justify the setting to the control board for my case.
I may have to use IP shifting instead if I can not work out the effects of the sticky dip on our other DIP pools.
I was hoping not to have to use IP Shift as this will involve me having to add 500 addresses to the firewall device as objects.
04-12-2012 03:08 AM
The simplest way to achieve this is a "subnet-to-subnet" MIP. Let's assume that the network used for the NAT is 172.16.1.0 255.255.254.0 and internal hosts are addressed as 192.168.2.0 255.255.255.0 and 192.168.3.0 255.255.255.0. In this case the command is:
set interface ethernetx/y mip 172.16.1.0 host 192.168.2.0 netmask 255.255.254.0
The MIP may not overlap with the interface IP or other already existing IPs. With other words, you should use a separate network. If this is impossible and you have to use the IPs from the interface network, multiple MIPs can be defined e.g. 172.16.1.64/26 -> 192.168.1.64/26, 172.16.1.128/25 -> 192.168.1.128/25, 172.16.2.0/24 -> 192.168.2.0/24.
Here I have assumed that the addresses 172.16.1.1-.63 are already occupied and interface IP is 172.16.1.1/23.
The network IPs and broadcast IPs are not wasted in such a configuration. A packet send to 172.16.1.64 will be correctly forwarded to 192.168.1.64 which is not a network address in the LAN.
Sure, you can also use a couple of DIP pools with shift. This might be a little bit complexer.
Sticky DIP does not solve your problem. It is applied to to the DIP pools with the PAT ENABLED. Besides, the sticky DIP does not create a persisent one-to-one relation. If all concurrent sessions from the same host have been closed and a new session is established after a while, a new IP will be taken, very likely, from the DIP pool for the src-NAT.
04-12-2012 05:45 AM
As I understand the original question, persistent one-to-one mapping is not a requirement here. Also, sticky DIP should make no difference for single-IP DIP pools because all sessions will use the same IP one way or another.
04-12-2012 06:07 AM
Thank you both for your comments/suggestions it is very much appreciated.
I believe Nikolay is correct with the MIP option. This will not help me for what I am trying to achive as I do need source address translation and not destination address translation.
I do not need the IP address for each of the 500 machines to be the same all the time. I do however need the address to stay the same during an active session where a user connects to the internet say skype or somehting like that and then that and all concurrent sessions the client initiates need then keep this IP address. The IP address only needs to stay the same for approx 2 hours during an internet browsing session.
The reason is we have an authntication device allowing users access to the internet after being authorised via this device. The device uses the IP address to say the user has authenticated. When the IP address changes this causes the authentication box to ask for re-authentication. This can happen swicthing frm page to page eg: swicthing from google to hotmail.
There are 500 clients which all need a unique IP address from the DIP pool hense a DIP pool of 500 addresses.
I was under the impression that using fix-port would do this but it is still changing the IP address after approx 10 mins of browsing when changing form one internet address to another. During the first 10 minutes it does keep the address when changing pages but it seems 10 mins is the max it lasts before chaning the IP address of the client.
I was also under the impression that using DIP sticky would resolve this but as you mentioned Eduardo this may not solve the issue.
I am guessing that I will have to use IP shift to get this to work correctly. I think I may need to log a call with the Juniper technical support to see if they can clarify the matter but am awaiting the renewal of our support contact before I can do this. I was hoping to work this out sooner.
04-12-2012 09:21 PM
Wait a second ... at what point does your upstream device "de-authenticate" a particular IP??? I think that's quite important here, because the moment a client stops all session, their DIP IP might immediately be taken by another client, so you should be worried whther the upstream device will notice the change or not. If it doesn't you may have cases of users jumping on each other's authentication sessions.
I think it would be safer, even if more difficult to configure, to require mapping persistance, and therefore use IP shifting in this case.
04-13-2012 12:48 AM
As stated in the ScreenOS documentation (sorry for a lengthy citation):
"Mapped IP (MIP) is a direct one-to-one mapping of one IP address to another. The
security device forwards incoming traffic destined for a MIP to the host with the
address to which the MIP points. Essentially, a MIP is static destination address
translation, mapping the destination IP address in an IP packet header to another
static IP address. When a MIP host initiates outbound traffic, the security device
translates the source IP address of the host to that of the MIP address. This
bidirectional translation symmetry differs from the behavior of source and destination
Besides, the MIP overrides the policy based src-NAT. So, if you configure a Trust-to-Untrust policy and enable a src-NAT to a DIP or to the egress interface IP, all mipped hosts will be src-natted to their MIP IPs while all other hosts will be src-natted as configured in the policy.
You will never get problems with authentication because all IP mappings are persistent.
The logs on your authentication device are useless if IP mappings change permanently. With MIPs you know always exactly who is/was doing what.
04-13-2012 05:20 AM
Thank you both for your input it was very much appreciated.
I managed to get a support case with Juniper support and we decided between us that IP shift was the best way to go although your suggestion witht he MIP would have also worked Edouard for my particular case for what I needed to achive the MIP would have caused me other issues due tot he nature of my authentication device. Traffic is only initiated in one direction and as it is only for internet access bi-directional traffic is not necessary. Also the original src address is a DHCP address and is for a public based internet solution so we will never know who is who really for this.
I did not have to type in 500 addresses also as I was able to do an IP range to another IP range and this gives me a one to one mapping solving my issue.
What we did in the end was:
set interface ethernet0/1 ext ip 192.168.0.1 255.255.254.0 dip 8 shift-from 10.160.0.11 to 192.168.0.11 192.168.1.254
Than applied the DIP pool to my policy from trust to untrust and all is working as it should with 10.160.0.11 nat to 192.168.0.11 and so on.
Thanks again for both your input's it was very much appreciated. As you both mentioned sticky DIP was not the way to go.
Also Edouard - the MIP solution will actually work for another sinareo I have so this solution you posted was very helpful too and your explanation is very clear.
Thank you both again for your help with this - very much appreciated.