Something I don’t see and don’t do very often is the configuration of a router including a 3G connection. So this blog post helps me during the process of configuring future connections. For todays configuration I am using the Dutch carrier KPN to establish the 3G connection. As hardware I am using a Cisco 888G router with a PCEX-3G-HSPA-G module. The most difficult during the configuration is the retrieval of the correct provider information. For this KPN connection is used the following credentials:
Don’t forget to use the above DNS servers when using a 3G connection from KPN. All other DNS servers, including Google’s DNS servers, won’t work.
The SIM card is locked by default with a password, so I first needed to unlock the SIM card. The unlocking of the SIM is accomplished with the following command:
router#cellular 0 gsm sim unlock <pin code>
The next thing to do is creating a gsm modem profile. With the modem profile you can configure different profiles with different APN, authentication, username and password combinations. For my connection I only need to specify the APN name, like shown below:
router#cellular 0 gsm profile create 1 fastinternet
Another important step is the configuration of a chat-script. The chat-script is used to define the Attention Dial Tone (ATDT) commands when the dialer is initiated. For gsm connections, the script always has the following syntax:
router(config)#chat-script <script name> “” “ATDT*99*<modem profile number>#” TIMEOUT <timeout value> CONNECT
Getting back to my configuration I configured the following chat-script:
router(config)#chat-script gsm-chat-script “” “ATDT*99*1#” TIMEOUT 30 “CONNECT”
Next you need to configure regular dial-on-demand (DDR) routing for the cellular interface. My cellular interface is used as the primary internet connection, so I included the necessary NAT statements on the interfaces.
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
dialer pool-member 1
async mode interactive
ip address negotiated
ip nat outside
ip virtual-reassembly in
dialer pool 1
dialer idle-timeout 0
dialer string gsm-chat-script
ppp chap hostname <APN name>
ppp chap password 0 <provider password>
ppp ipcp dns request
no cdp enable
dialer-list 1 protocol ip permit
The last two steps involve the configuration of a default route and line configuration mode. I configure a regular default route with the Dialer 1 interface as next-hop interface. The line configuration mode, includes the following commands for the KPN connection.
script dialer gsm-chat-script
That’s it. Just configure a routed or VLAN interface. Some NAT and ACL statements and you are ready to go. You can use several
show cellular 0 <commands>
commands for troubleshooting or information about your connection.
By default, remote access VPN users aren’t able to manage a Cisco ASA firewall on the inside interface using any kind of management protocol (SSH, telnet, HTTPS).
You can enable remote management by specifying the management-access interface. You can specify the interface via the CLI or via the Cisco Adaptive Security Device Manager (ASDM). Both methods are specified below.
fw01/booches.nl/act# configure terminal
fw01/booches.nl/act(config)# management-access inside
When using the Management Access feature with remote VPN connections (IPSec or SSL VPN) don’t forget to add the VPN pool to the corresponding management access protocols on the interface you specified as management access interface
I tried to configure a Citrix Web Interface 5.3 server in conjunction with Citrix Presentation Server / XenApp 4.0 and a NetScaler. It is possible to login, but I cannot launch an application. When trying to launch an application I receive the following error message:
An error occurred while making the requested connection
I found an related article on the Citrix website. This article applies to Web Interface 5.2, but also works for Web Interface 5.3 The symptoms in the EventViewer for Web Interface 5.3 are different, but gives me more specifications about the problem. In the event log of the Web Interface 5.3 server you will receive the following error message.
After changing the RequireLaunchReference parameter in \inetpub\wwwroot\Citrix\XenApp\Conf\WebInterface.conf applications can be launched without any problems.
Add On: if the above solution doesn’t work, then a second solution for this problem can be found here
While checking interface statistics on a Cisco 3845, I noticed the following layer 3 interfaces.
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 126.96.36.199 YES NVRAM up up
GigabitEthernet0/1 10.10.10.1 YES NVRAM up up
GigabitEthernet0/0/0 unassigned YES NVRAM administratively down down
SSLVPN-VIF0 unassigned NO unset up up
Tunnel0 192.168.255.2 YES NVRAM up up
I can explain all interfaces, except the SSLVPN-VIF0 interface. I tried to look at the internet, but that didn’t result in any useful information. I used Cisco’s Output Interpreter, but that didn’t help either.
INFO: The following interfaces show the interface configuration ‘method’ as ‘unset’. SSLVPN-VIFO This means that no configuration changes were made to the interface since the last reload.
I noticed the same interface on a Cisco 1811 router, but not on the Cisco 871 and Cisco 878 routers. The interface cannot be related to SSL VPN functionalities, because that feature isn’t configured on the routers. At least that was what I thought at first. I checked my home router, because it has SSL VPN configured and found that the SSLVPN-VIF0. As the abbreviation implies, SSLVPN-VIF0 stands for “SSLVPN Virtual Interface 0”.
An IP address is assigned to the interface, after establishing a SSLVPN connection. You can retrieve more information about the SSLVPN-VIF interface by using multiple show interface SSLVPN-VIF commands. An example is shown below:
router#show interface SSLVPN-VIF 0 switching
SSLVPN-VIF0 ***Internally created by SSLVPN context home***
Switching path Pkts In Chars In Pkts Out Chars Out
Process 26 2657 4 240
Cache misses 0 – – –
Fast 0 0 0 0
Auton/SSE 0 0 0 0
NOTE: all counts are cumulative and reset only after a reload.
So don’t panic when you see the SSLVPN-VIF0 interface on your router. You now know where it is coming from.
Last week I had a very strange problem with a Cisco ASA firewall. The firewall is configured with multiple interfaces, including a DMZ interface. There are multiple servers in the DMZ. These servers are physical and virtual servers. The virtual servers are VMware servers in a blade environment.
I configured the feature
ip verify reverse-path interface DMZ
to prevent spoofing to occur. I also configured a transparent static NAT rule between the Inside network and the DMZ network and multiple static NAT rules between the DMZ network and the Outside network. I left the proxy ARP feature configured with its default settings.
The customer was complaining about log in problems and connectivity problems on the DMZ servers, especially between different DMZ servers. I have done some research and noticed that all problems were related to DMZ servers in the blade environment.
I started some connectivity test and noticed some strange ICMP behavior on the specific servers. When I started a ping from one DMZ VMware server to an other DMZ server on the same ESX host, the first ping responded with an echo-reply, but consequent pings failed. Looking at the ARP table of the server, I noticed that the firewall responded with its own MAC address for every ARP broadcast.
Looking at different forums on the Internet, everybody is speaking about the proxy ARP feature and that you should disable this feature. By default proxy ARP is enabled and I always leave it enabled. Till now I never had this problem. After disabling the proxy ARP feature for the DMZ interface
sysopt noproxyarp DMZ
the problem was solved, because the firewall doesn’t respond to the ARP queries, except for its own interface. Digging a bit deeper on forums, I never found one thread who explains why the proxy ARP feature should be disabled to solve this particular problem.
In my opinion this problem is related to the VMware environment, because I don’t have these problems with physical DMZ servers. So it is strange why the DMZ servers on the same ESX hosts cannot see each other and why does the firewall respond to the ARP queries?
In the near future the blade environment (ESX hosts, network configuration and SAN configuration) is changed, so I hope to find the exact cause and solution of the problem. Does anybody else have some suggestions??