Can not VPN tunnel through dial up connection after 07/11/12

[POS_Tech]

Since I received a Windows update on 07/11 containing the following security updates:
KB2655992, KB2691442, KB2698365, KB2718523, KB2719985
When I dial into a remote server via my PC COMM1 I am not able to connect via my OVPN tunnel as I could before 07/11. (even after uninstalling these updates we still cant make the OVPN connection)

My client.ovpn contains:
**********
# how chatty
verb 5

# which device to use
dev tun

# Shared secret for increased packet security.
tls-auth ta.key 1

#the following are to use PAM user/password prompt for 2-factor auth
auth-user-pass

# allows the server to send configuration to the client (ip and route)
pull

# this is a client for negotiations
tls-client
tls-remote mgr

# the certs and keys needed to establish/verify identity
cert user.pem
key user.key
ca cacert.pem


proto udp
nobind
persist-key
persist-tun
************

After logging into server via dial up, when I try to open the Tunnel I see:
************
Enter site to connect to:192.168.1.80
Fri Jul 13 14:37:34 2012 us=269469 OpenVPN 2.3_alpha2 i686-w64-mingw32 [SSL (Ope
nSSL)] [LZO] [PKCS11] [eurephia] [PF_INET6] [IPv6 payload 20110522-1 (2.2.0)] bu
ilt on Jul 4 2012
Enter Auth Username:XXXXXX (MASKING)
Enter Auth Password:
Fri Jul 13 14:37:40 2012 us=440822 WARNING: Make sure you understand the semanti
cs of --tls-remote before using it (see the man page).
Fri Jul 13 14:37:40 2012 us=441822 NOTE: OpenVPN 2.1 requires '--script-security
2' or higher to call user-defined scripts or executables
Fri Jul 13 14:37:40 2012 us=713838 Control Channel Authentication: using 'ta.key
' as a OpenVPN static key file
Fri Jul 13 14:37:40 2012 us=713838 Outgoing Control Channel Authentication: Usin
g 160 bit message hash 'SHA1' for HMAC authentication
Fri Jul 13 14:37:40 2012 us=713838 Incoming Control Channel Authentication: Usin
g 160 bit message hash 'SHA1' for HMAC authentication
Fri Jul 13 14:37:40 2012 us=713838 Control Channel MTU parms [ L:1541 D:166 EF:6
6 EB:0 ET:0 EL:0 ]
Fri Jul 13 14:37:40 2012 us=738839 Socket Buffers: R=[8192->8192] S=[8192->8192]

Fri Jul 13 14:37:40 2012 us=738839 Data Channel MTU parms [ L:1541 D:1450 EF:41
EB:4 ET:0 EL:0 ]
Fri Jul 13 14:37:40 2012 us=738839 Local Options String: 'V4,dev-type tun,link-m
tu 1541,tun-mtu 1500,proto UDPv4,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tl
s-auth,key-method 2,tls-client'
Fri Jul 13 14:37:40 2012 us=739839 Expected Remote Options String: 'V4,dev-type
tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,keydir 0,cipher BF-CBC,auth SHA1,keys
ize 128,tls-auth,key-method 2,tls-server'
Fri Jul 13 14:37:40 2012 us=739839 Local Options hash (VER=V4): '70f5b3af'
Fri Jul 13 14:37:40 2012 us=740839 Expected Remote Options hash (VER=V4): 'a2e24
98c'
Fri Jul 13 14:37:40 2012 us=741839 UDPv4 link local: [undef]
Fri Jul 13 14:37:40 2012 us=742839 UDPv4 link remote: [AF_INET]192.168.1.80:1194

WWWWW
***************
I am however able to connect to these servers via dialup/vnp IF I set the shared connection for the dial up adapter to TRUE and point to the "Local Area Connection", This is a very poor solution for me though, as it cripples the Local Area Connection and we cant navigate through our local servers anymore. Before we could dial in and then tunnel and still be able to work on both the remote server and the local servers.

Has anyone else experienced anything like this since the windows updates(maybe this is a red herring?)? Or does anyone have any suggestions on configurations that we can use to resolve this issue.

Any input would be greatly appreciated.