Below shows how to configure Static nat for a web server or some kind of application running on a internal host. Basically we are port forwarding port 80 from our public IP of 1.1.1.2 to port 80 of our internal IP at 10.1.1.2. In this example Auto Nat will be used. You could also use Manual nat, I have written another blog entry on this. This is way different than 8.2 and below. Here we create an object and then modify the object with the Static port forward we want. I
In this example my ASA outside IP is 1.1.1.1, and I want the web server to answer on 1.1.1.2.
object network 1.1.1.2
host 1.1.1.2
exit
object network 10.1.1.2
host 10.1.1.2
nat (inside,outside) static 1.1.1.2 service tcp 80 80
Somethings to note- We could name the objects anything, I just chose to use the actual IP address. For example, you could do the command ” object network Webserver-Outside” and use that name to reference the outside IP address.
Next, if I want to allow access to 10.1.1.2 from the outside world, I will need an ACL.
access-list Outside-In permit tcp any 10.1.1.2 eq 80
access-group Outside-In in interface outside
Notice the internal IP specified in the ACL – that is there on purpose. Instead of referencing the External IP you now reference the internal.
What if the outside address answering for my web server is the outside IP of the ASA?
No problem, just have to modify that one NAT entry. Instead of the public NAT object we use the “interface” keyword.
object network 1.1.1.2
host 1.1.1.2
exit
object network 10.1.1.2
host 10.1.1.2
nat (inside,outside) static interface service tcp 80 80
Recently I was working on a project that had a very remote office that could not get high speed connections to its location. So, they wanted to combine 4 T1s that were already in the building to boost throughput. I had done this exact thing with many different ISPs but never Verizon/MCI . They do things just a bit different, so this entry is about what is needed to combine these links on Verizon’s network.
The key here is to use a Multilink Frame relay interface. This is a Virtual interface that will combine the individual interfaces. Its very similar to a BVI in concept. As Cisco says it: The Multilink Frame Relay feature enables you to create a virtual interface called a bundle or bundle interface. The bundle interface serves as the Frame Relay data link and performs the same functions as a physical interface.
At the bottom of this entry all the parts of the config are listed
First we needed to create the MFR interface itself. The number is up to you, I created 34 – feel free to change that.
interface MFR34
mtu 4470 — MTU Verizon said to set
no ip address
no ip redirects
encapsulation frame-relay IETF – Encapsulation used.
frame-relay multilink bid u11111-11
frame-relay lmi-type ansi
!
Next we need to create the sub interface , which will be used as our DLCI and our L3 interface.
interface MFR34.500 point-to-point
description multilink:MLFR:3xT1
bandwidth 6000
ip address x.x.x.x x.x.x.x
ip nat outside
snmp trap link-status
no cdp enable
no arp frame-relay
frame-relay interface-dlci 500 IETF
!
Then we will bond the interface to our MFR interface.
interface Serial0/0/0:0
mtu 4470
bandwidth 1536
no ip address
encapsulation frame-relay MFR34
load-interval 30
cdp enable
no arp frame-relay
!
The T1 and MFR config are below:
controller T1 0/0/0
cablelength long 0db
channel-group 0 timeslots 1-24
!
controller T1 0/0/1
cablelength long 0db
channel-group 0 timeslots 1-24
!
controller T1 0/0/2
cablelength long 0db
channel-group 0 timeslots 1-24
!
controller T1 0/0/3
cablelength long 0db
channel-group 0 timeslots 1-24
!
interface MFR34
mtu 4470
no ip address
no ip redirects
encapsulation frame-relay IETF
frame-relay multilink bid u11111-11
frame-relay lmi-type ansi
!
interface MFR34.500 point-to-point
description multilink:MLFR:3xT1
bandwidth 6000
ip address x.x.x.x x.x.x.x
ip nat outside
snmp trap link-status
no cdp enable
no arp frame-relay
frame-relay interface-dlci 500 IETF
!
interface Serial0/0/0:0
mtu 4470
bandwidth 1536
no ip address
no ip redirects
no ip proxy-arp
encapsulation frame-relay MFR34
load-interval 30
cdp enable
no arp frame-relay
!
interface Serial0/0/1:0
mtu 4470
bandwidth 1536
no ip address
no ip redirects
no ip proxy-arp
encapsulation frame-relay MFR34
load-interval 30
no arp frame-relay
!
interface Serial0/0/2:0
mtu 4470
bandwidth 1536
no ip address
no ip redirects
no ip proxy-arp
encapsulation frame-relay MFR34
load-interval 30
no arp frame-relay
!
interface Serial0/0/3:0
mtu 4470
bandwidth 1536
no ip address
no ip redirects
no ip proxy-arp
encapsulation frame-relay MFR34
load-interval 30
no arp frame-relay
!
Recently I was asked about how to add a nic to a Vyatta VM, my reply “add it in VMware and reboot”- their response “We cannot reboot”. I asked why they can’t reboot and they said “If we were to reboot this Vyatta (Bring down the Client VPNs) then we would have to send out an email a ton of clients and let them know” – huge ordeal .
So we need to add a nic via VMware, and then have Vyatta recognize that nic right away, with out a reboot. So I added the Nic (see image below) in VMware:
After I add the NIC, I can look on the Vyatta and see it still shows only two NICs.
So, VMware added the nic but Vyatta(debian) never sees it. After trying to ifup/ifdown , service network restart – and many other commands it could never find it.
So, what is needed – we have to rescan the PCI bus to find the nic. Most Linux users are probably like — ya of course you do! But I just reboot and it works. In this case cant reboot.
To Rescan the PCI bus, we have to first change our permissions on that file, echo into that file, than change the permissions back. The commands to do so are:
configure
sudo chmod 0777 /sys/bus/pci/rescan
sudo echo 1 > /sys/bus/pci/rescan
sudo chmod 0220 /sys/bus/pci/rescan
After doing that look at your interfaces:
Now we see the interface and can configure it. This process should work with Debian no problem (since Vyatta is Debian).
Recent Comments