{"id":808,"date":"2012-01-09T17:04:09","date_gmt":"2012-01-09T17:04:09","guid":{"rendered":"http:\/\/blogs.oucs.ox.ac.uk\/networks\/?p=808"},"modified":"2012-01-10T10:26:28","modified_gmt":"2012-01-10T10:26:28","slug":"vpn-nat-changes","status":"publish","type":"post","link":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/2012\/01\/09\/vpn-nat-changes\/","title":{"rendered":"VPN NAT Changes"},"content":{"rendered":"<h3>What is this post about?<\/h3>\n<p>We are planning to make a minor change to the way our VPNs NAT clients. For those who are interested, this blog post explains why and how we are doing this. Please note that these days NAT is used as a general term encompassing both NAT (Network Address Translation) and PAT (Port Address Translation). I&#8217;ll be specific in this post.<\/p>\n<h3>Problem summary<\/h3>\n<p>The original VPN config didn&#8217;t use NAT or PAT and had a client pool of\u00a0<code>129.67.116.0\/22<\/code>, which was advertised to the various departmental and collegiate IT staff working at Oxford University. This pool became exhausted but we don&#8217;t want to be seen to be favouring our own services by taking whatever IPs we would like. Also there are lots of local firewalls around the University which are aware of this range so we migrated to PAT, taking 2 IPs from the above range per ASA.<\/p>\n<p>At the time of writing (Jan 2012), the ASA VPNs are configured as follows, where X and Y are two adjacent IPs and are unique to each ASA:<\/p>\n<pre>object network <strong>nat_inside_local<\/strong>\r\n subnet 10.16.0.0 255.255.240.0\r\nobject network <strong>nat_outside_pool<\/strong>\r\n range 129.67.119.24X 129.67.119.24Y\r\nnat (vpn-outside,vpn-inside) \\\r\n source dynamic <strong>nat_inside_local<\/strong> pat-pool <strong>nat_outside_pool<\/strong><\/pre>\n<p>This means that hosts in 10.16.0.0\/20 whose traffic hits the vpn-outside interface and is destined for the vpn-inside interface, will be PATed onto 129.67.119.24X. When all 65K ports have been used up, .24Y will be used. The issue we are having is that IP\/Port combinations are being re-used too quickly for our CERT team to be certain (ha ha) of who is being naughty.<\/p>\n<h3>Solution<\/h3>\n<p>To get around this we will move to using Dynamic NAT with a generous range of IPs, falling back to a PAT IP if they are exhausted. We need to take care when choosing the pools though as some IPs are reserved for existing VPN infrastructure. As such the allocation of the pools will asymetrical as to me this seems cleaner than giving 9 hosts from .117 to node 1.<\/p>\n<ul>\n<li>node0 will have\u00a0<code>129.67.116.1 - 129.67.117.2<strong>5<\/strong>5<\/code><\/li>\n<li>node1 will have\u00a0<code>129.67.118.0 - 129.67.119.2<strong>3<\/strong>5<\/code><\/li>\n<\/ul>\n<p>The \/22 contains a few addresses which will look odd. Namely 116.255, 117.[0|255], 118.[0|255], 119.0 are all legitimate. We will waste 118.0 as it means both PAT addresses will be silimar which should make life a bit easier.<\/p>\n<p>116.0 and 119.255 are the only network and broadcast addresses.<\/p>\n<p>The final config will be as follows. I&#8217;ve renamed the groups to simplify migration and hopefully make it very clear what is going on.<\/p>\n<h4>vpn-0<\/h4>\n<pre>object network D-NAT-RANGE\r\n <strong>range<\/strong> <strong>129.67.116.2 129.67.117.255<\/strong>\r\nobject network PAT-HOST\r\n<strong> host 129.67.116.1<\/strong>\r\nobject network INSIDE-POOL\r\n <strong>subnet<\/strong> <strong>10.16.0.0 255.255.240.0<\/strong>\r\nobject-group network OUTSIDE-POOL\r\n network-object object D-NAT-RANGE\r\n network-object object PAT-HOST\r\n\r\nnat (vpn-outside,vpn-inside) \\\r\n source dynamic INSIDE-POOL OUTSIDE-POOL<\/pre>\n<h4>vpn-1<\/h4>\n<pre>object network D-NAT-RANGE\r\n <strong>range<\/strong> <strong>129.67.118.2 129.67.119.235<\/strong>\r\nobject network PAT-HOST\r\n<strong> host 129.67.118.1<\/strong>\r\nobject network INSIDE-POOL\r\n <strong>subnet<\/strong> <strong>10.16.16.0 255.255.240.0\r\n<\/strong>\r\nobject-group network OUTSIDE-POOL\r\n network-object object D-NAT-RANGE\r\n network-object object PAT-HOST\r\n\r\nnat (vpn-outside,vpn-inside) source dynamic INSIDE-POOL OUTSIDE-POOL<\/pre>\n<p>All three objects are unique on each host.<\/p>\n<h3>Staging tests<\/h3>\n<p>I used our lab to mimic the production environment. We tested with four clients so needed to artifically shrink the Dynamic NAT range to 2 IPs so that PAT would be triggered and we could verify it worked. We used only one ASA for the same reason, here is the config:<\/p>\n<pre>object network D-NAT-RANGE\r\n range 192.168.30.12 192.168.30.13\r\nobject network PAT-HOST\r\n host 192.168.30.31\r\nobject network INSIDE-POOL\r\n subnet 10.0.0.0 255.255.255.0\r\nobject-group network OUTSIDE-POOL\r\n network-object object D-NAT-RANGE\r\n network-object object PAT-HOST\r\n\r\nnat (vpn-outside,vpn-inside) source dynamic INSIDE-POOL OUTSIDE-POOL<\/pre>\n<h3>Verification<\/h3>\n<p>The first two hosts to connect were NATed to 192.168.30.12 and .13 respectivly. The remaining two hosts use PAT on .31. All hosts were able to reach the appropriate fake external networks hosted on an area of the lab only reachable from the VPN pool.<\/p>\n<p>With three laptops connected we see the first two use 1-1 dynamic NAT and the third uses PAT:<\/p>\n<pre>vpn-dev-0# show xlate\r\n4 in use, 7 most used\r\nFlags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice\r\nNAT from vpn-outside:10.0.0.1 to vpn-inside:192.168.30.12 \\\r\n flags i idle 0:00:09 timeout 3:00:00\r\nNAT from vpn-outside:10.0.0.2 to vpn-inside:192.168.30.13 \\\r\n flags i idle 0:00:17 timeout 3:00:00\r\nTCP PAT from vpn-outside:10.0.0.3\/53013 to vpn-inside:192.168.30.31\/42959 \\\r\n flags ri idle 0:00:00 timeout 0:00:30\r\nTCP PAT from vpn-outside:10.0.0.3\/53012 to vpn-inside:192.168.30.31\/20628 \\\r\n flags ri idle 0:00:01 timeout 0:00:30<\/pre>\n<p>Now with four laptops connected the additional client also used PAT:<\/p>\n<pre>vpn-dev-0# show xlate\u00a0\r\n36 in use, 36 most used\r\nFlags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice\r\n&lt;snip&gt;\r\nUDP PAT from vpn-outside:10.0.0.4\/52004 to vpn-inside:192.168.30.31\/60697 \\\r\n\u00a0flags ri idle 0:00:45 timeout 0:00:30\r\nUDP PAT from vpn-outside:10.0.0.4\/137 to vpn-inside:192.168.30.31\/252 \\\r\n\u00a0flags ri idle 0:01:25 timeout 0:00:30\r\nNAT from vpn-outside:10.0.0.1 to vpn-inside:192.168.30.12 \\\r\n\u00a0flags i idle 0:00:00 timeout 3:00:00\r\nNAT from vpn-outside:10.0.0.2 to vpn-inside:192.168.30.13 \\\r\n\u00a0flags i idle 0:00:10 timeout 3:00:00\r\nICMP PAT from vpn-outside:10.0.0.3\/51467 to vpn-inside:192.168.30.31\/26251 \\\r\n\u00a0flags ri idle 0:01:51 timeout 0:00:30<\/pre>\n<p>Our policy is in use:<\/p>\n<pre>vpn-dev-0# show nat\r\nManual NAT Policies (Section 1)\r\n1 (vpn-outside) to (vpn-inside) \\  source dynamic INSIDE-POOL OUTSIDE-POOL\r\ntranslate_hits = 59, untranslate_hits = 126<\/pre>\n<h3>Sumary<\/h3>\n<p>We plan to make this change live during our next maintenance release.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>What is this post about? We are planning to make a minor change to the way our VPNs NAT clients. For those who are interested, this blog post explains why and how we are doing this. Please note that these &hellip; <a href=\"https:\/\/blogs-new.it.ox.ac.uk\/networks\/2012\/01\/09\/vpn-nat-changes\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":12,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13,278,11,126],"tags":[],"class_list":["post-808","post","type-post","status-publish","format-standard","hentry","category-cisco-networks","category-documentation","category-general-maintenance","category-vpn-services"],"_links":{"self":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts\/808","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/users\/12"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/comments?post=808"}],"version-history":[{"count":23,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts\/808\/revisions"}],"predecessor-version":[{"id":831,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts\/808\/revisions\/831"}],"wp:attachment":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/media?parent=808"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/categories?post=808"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/tags?post=808"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}