Connecting the world…

interface

Cisco 888G with KPN 3G connection

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:

  • – APN name: fastinternet
  • – PPP CHAP username: <empty>
  • – PPP CHAP password: <empty>
  • – DNS: ns1.kpn-gprs.nl (62.133.126.28) & ns2.kpn-gprs.nl (62.133.126.29)

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.

interface Cellular0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer in-band
dialer pool-member 1
async mode interactive

!
interface Dialer1
ip address negotiated
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer string gsm-chat-script
dialer persistent
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.

line 3
script dialer gsm-chat-script
modem InOut
no exec
rxspeed 7200000
txspeed 5760000

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.

Cisco ASA remote management via VPN

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.

CLI

fw01/booches.nl/act# configure terminal
fw01/booches.nl/act(config)# management-access inside

ASDM

asa-management

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

Citrix Web Interface 5.3: An error occurred while making the requested connection

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.

webinterface_launch_reference

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

Huh? Interface SSLVPN-VIF0?

While checking interface statistics on a Cisco 3845, I noticed the following layer 3 interfaces.

Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         74.124.155.67   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***

Protocol  IP
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.

Cisco ASA & ESX: strange ARP behavior

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??