Network switching issues with MacOS 10.7?

I'm having a weird problem and hope somebody can tip me, what way should I dig to.

I'm using MacBookPro with Lion 10.7.3 both at my working place & at home.

At working place, we have a domain-based network with 802.1x authorization (more than 400 computers) and to connect it I'm using Ethernet cable. IP range is 10.10.2.*. All network settings are setup automatically by DHCP. Also, in settings, I have Network Account Server setup in the User&Groups Settings for my work Domain server - and it is available only from corporate network.

At home, I have an ADSL router, that shares Internet connection by WiFi in NAT mode. I'm using WiFi to connect it. Router gives out addresses from 192.168.1.* range and all settings are also set up by router's DHCP.

So, my problem is the following. When I come back home from the office, I open my MacBook and AirPort automatically connects my WiFi network. After this, for about 1 minute I'm able to browse sites & ping hosts successfully. But after this minute, network connection is broken down. All pings return time-out. trace route to google.com stops on 192.168.1.1 (which is my router). This lasts for 3-4 minutes. After that network connection is automatically repaired and all pings go smoothly again. At the same time, when my MacBook return timeouts, I can successfully ping any host from my wife's MacBook - so this doesn't look like router issue. When I come to the office, I don't have any issues and Internet connection is available & stable moments after ethernet cable plugged in.

Do anybody has any clues about this? What should I monitor & what settings look for resolving this issue? Please, ask, what additional information should I provide.

Hoping for good advice & thanks in advance!

UPDATE:

ifconfig en1 results

for state, when ping fails

DenisMBP:CrowdedIsland denis$ ifconfig en1
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 60:33:4b:12:38:60 
    inet6 fe80::6233:4bff:fe12:3860%en1 prefixlen 64 scopeid 0x5 
    inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
    media: autoselect
    status: active

for state, when pings are ok

DenisMBP:CrowdedIsland denis$ ifconfig en1
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 60:33:4b:12:38:60 
    inet6 fe80::6233:4bff:fe12:3860%en1 prefixlen 64 scopeid 0x5 
    inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
    media: autoselect
    status: active

UPDATE 2: I've added a cut from Console.app log, displaying the moment of Macbook wakeup, working connection, broken connection. You can get it here

UPDATE 3: I've made log of netstat & ifconfig calls for all of three states. You can found it here

UPDATE 4: I've uninstalled Cisco AnynetConnect VPN Client and issue is still reproducible. Here's log for netstat & ifconfig log file. And here's log from Console.app (see netstat log for finding time points, when network was working and was not) log file

Solution 1:

Update: It wasn't the VPN client causing this, but after lengthy troubleshooting (see comments) it turned out to be Skype, possibly due to UPnP related bugs.

Try disabling your Cisco AnyConnect(?) VPN client (if you're not sure how, open Activity Monitor, find a process named acvpnagent and quit it).

From your description, it may well be the case that the VPN client is either failing to establish a tunnel or taking a rather long to do so, either of which could cause the apparent loss of the default route you're describing (you can ping anything on your local network, but nothing past the router).

If disabling the above (and any other) VPN client doesn't resolve it, please add the results of:

• ifconfig (not just ifconfig en1 - there's an interface utun0 appearing in your log)
• netstat -rnfinet

... at each of these stages:

• immediately after connecting to your Wifi (while the network seems to be up)
• during the problem
• and after recovery

Solution 2:

I have seen something similar to this; I do not have a fix (wish I did).

The problem is that Lion speculatively brings up the interface immediately with its last known address (presumably based on the router or AP; it does store that information in one of the system plists), while querying the DHCP server to find out if that address is actually available. If the DHCP server returns DHCPNAK, the interface becomes unconfigured while it properly negotiates a new address, at which point the interface is brought back up.

Theoretically (although probably not in practice on a small home network) your computer could have the same address as another computer on the network during that initial speculative phase.