How do you make all traffic pass through the VPN?

[Timerift]

On my Mac or PC or even my Nexus it seems that all traffic will pass through OPENVPN, but on my iPad Air only traffic for safari is passing through. Now in the settings for iPad or iPhone when looking at a VPN profile it seems you can say that all traffic will go through the VPN but that doesn't seem to be the case with OPENVPN. So because of some blocks at my work I can't get google mail or my sling box, or even Facetime to work because traffic isn't going through the VPN and it's being blocked. They do work on OPENVPN on my Mac or PC or Android device though. Again I'm using an iPad Air which is on IOS7. Any ideas?

[whatsmyusername]

I'm trying to do the same thing. The solutions I've found so far indicate you may be able to add this to your iOS client ovpn config file:

redirect-gateway def1

I've tried this without success. I'm thinking there's more to the server configuration (am running ovpn community server on Windows 7), but haven't found a solution yet. I can add this redirect-gateway def1 line to my client config, but when I try access anything on my iOS device, say, in Safari, the web pages hang.

If you're running Windows 7 as the ovpn server, take a look at topic7806.html. I haven't gotten all the way through it yet, but it may help answer some of your questions.

Also, just FYI, while I won't be able to help much more than this, others may. If/when they do, you're going to get asked for more details on what OS your server is on, as well as the entire text of your server and client config files.

[Timerift]

Thank for the advice. I'll give it a try. Here is what my current config file looks like:

client
remote ios-d2.proxpn.com 443
dev tun
proto tcp
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 4
mute 5
tun-mtu 1500
mssfix 1450
auth-user-pass
reneg-sec 3600

route-method exe
route-delay 1 10
route-metric 512
route 0.0.0.0 0.0.0.0
tls-client

<ca>
-----BEGIN CERTIFICATE-----
MIIFADCCA+igAwIBAgIJANJevG4eanbDMA0GCSqGSIb3DQEBBQUAMIGwMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCQ0ExFTATBgNVBAcTDFNhbkZyYW5jaXNjbzEbMBkG
A1UEChMScHJvWFBOIERpcmVjdCwgTExDMRMwEQYDVQQLEwpwcm94cG4uY29tMRMw
EQYDVQQDEwpwcm94cG4uY29tMRMwEQYDVQQpEwpwcm94cG4uY29tMSEwHwYJKoZI
hvcNAQkBFhJzdXBwb3J0QHByb3hwbi5jb20wHhcNMTAwNjA4MTQ0NDExWhcNMjAw
NjA1MTQ0NDExWjCBsDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRUwEwYDVQQH
EwxTYW5GcmFuY2lzY28xGzAZBgNVBAoTEnByb1hQTiBEaXJlY3QsIExMQzETMBEG
A1UECxMKcHJveHBuLmNvbTETMBEGA1UEAxMKcHJveHBuLmNvbTETMBEGA1UEKRMK
cHJveHBuLmNvbTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBwcm94cG4uY29tMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAug1oqmSJ6pL4p2B9vr0dx9UM
FihYyJQAG466plFbotHXQwW09s9Tn2qDxaJobCb7uX5d6ax/4ZzAipqBTxDncO05
CX2w03fWx2acFmRp+HILHQ/MjiYNpqp0DlRRYG9IC98c09xRs3qCtwnP8KTegcdA
5O9GbygT8BpAmFHMy/x9rGgnbQQxoDx/Lb16nCHvZouuQ1m8Vw7knygRe/nLLlzx
yM/wHViLqZiQB3pNlOPyBPLZa7RjNMtsl7LFw+ah9y8Mdfvtc8q5C5z78mgRDTyF
Ild90i/7CbZjcZLGDz7G7pKSxeiAOD4OkHRQA6/OzhVRGaFEsyZH4HuGGrLtXwID
AQABo4IBGTCCARUwHQYDVR0OBBYEFKvNJBpQvaxDdI1exwLB7dJayPrjMIHlBgNV
HSMEgd0wgdqAFKvNJBpQvaxDdI1exwLB7dJayPrjoYG2pIGzMIGwMQswCQYDVQQG
EwJVUzELMAkGA1UECBMCQ0ExFTATBgNVBAcTDFNhbkZyYW5jaXNjbzEbMBkGA1UE
ChMScHJvWFBOIERpcmVjdCwgTExDMRMwEQYDVQQLEwpwcm94cG4uY29tMRMwEQYD
VQQDEwpwcm94cG4uY29tMRMwEQYDVQQpEwpwcm94cG4uY29tMSEwHwYJKoZIhvcN
AQkBFhJzdXBwb3J0QHByb3hwbi5jb22CCQDSXrxuHmp2wzAMBgNVHRMEBTADAQH/
MA0GCSqGSIb3DQEBBQUAA4IBAQAve0ODYMpPYaKapzivsX8Tr0tp3HIosichqVzs
d1y29ZT1bEqYGAoNOVWcz6nXYP/MDwpU1MJ4EZn5HUX2SPiDOPThqgdfc9KvUc91
pUG49XTD6q3V3j1lvU0nNqmAo+igamq0IGIQwq0xld2nrjTfSB6u87fPSG1mZuPU
Jjci03/CrFTDT90GFQr+s2aszrxJu2YaKB69XF66x7zwYYYHipJ/THiqBZFwMl4t
8ew06qlN5NwclhnMmNumj9MSr+V+kgKryp09o0PIUr3p19Rv2wIILJ3MuWHQc+01
iMWIdmaw17lrIb22Pws7PWTY44RPDBHhZXUU6/ljNJ9qgVgf
-----END CERTIFICATE-----
</ca>

<cert>
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com/name=proxpn.com/emailAddress=support@proxpn.com
Validity
Not Before: Jun 8 14:45:12 2010 GMT
Not After : Jun 5 14:45:12 2020 GMT
Subject: C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com/name=proxpn.com/emailAddress=support@proxpn.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:e0:93:70:eb:4b:6a:7b:c1:2c:1b:27:dd:fd:7e:
a1:10:ef:97:02:93:ee:b4:84:ce:a6:5c:71:03:2c:
66:ef:a5:20:f1:4b:dc:48:35:6a:a6:d2:b0:d8:eb:
03:fe:6d:6e:2a:5c:97:5a:bc:8a:bc:5a:f5:7d:98:
d5:c1:b8:d6:8d:c6:84:d5:2a:53:47:64:12:41:7d:
58:ca:24:d5:49:35:02:f4:c1:1d:a6:f9:e2:62:c2:
21:0b:ef:c5:1f:c7:d3:75:66:6c:89:7c:b3:82:04:
2a:ef:fd:f2:90:5c:c1:ce:15:25:3b:5c:47:a3:59:
69:5b:7d:59:b2:20:77:92:49:0a:c6:dc:f7:40:16:
3c:d2:1f:e7:78:87:8c:f7:b1:2d:32:b5:dd:ff:4e:
5d:2912:89:0a:75:65:e3:a4:0a:1b:30:5a:58:
4d:a4:ba:e6:09:5d:0f:fc:47:9b:56:3d:83:08:a3:
99:80:d3:e3:b9:3d:75:26:bb:ad:2f:e5:9b:54:aa:
83:89:86:eb:77:e5:55:a7:4b:98:62:42:9a:1e:52:
5b:e7:da:cb:b9:c9:e9:b4:68:0c:04:10:cb:f5:bc:
84:08:2d:8b:c6:f3:81:aa:57:6a:b6:bf:aa:bb:fe:
79:7e:87:64:45:21:39:fd:f0:b2:b7:14:ec:52:3a:
dc:0d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
Easy-RSA Generated Certificate
X509v3 Subject Key Identifier:
22:75:DD:59:51:30:D1:D7:88:80:A1:4C:99:A0:49:23:D8:32:70:5B
X509v3 Authority Key Identifier:
keyid:AB:CD:24:1A:50:BD:AC:43:74:8D:5E:C7:02:C1:ED:D2:5A:C8:FA:E3
DirName:/C=US/ST=CA/L=SanFrancisco/O=proXPN Direct, LLC/OU=proxpn.com/CN=proxpn.com/name=proxpn.com/emailAddress=support@proxpn.com
serial:D2:5E:BC:6E:1E:6A:76:C3

X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature
Signature Algorithm: sha1WithRSAEncryption
aa:2c:dc:02:2b:c0:37:a4:4d:d3:88:f4:ae:f5:3a:be:d3:80:
76:8d:f1:85:36:7a:7e:e2:c5:65:cf:09:03:b1:fb:bd:12:ef:
c8:8b:18:64:d7:97:d9:41:fe:64:ce:ce:4e:e8:14:30:69:49:
cf:da:73:16:fd:1b:da:23:aa:71:96:9d:2d:a8:d5:ea:1b:c6:
8e:01:11:4b:36d0:ba:4e:89:66:94:94:7f47:00:f3:
5f:00:69:2e:c3:e2:be:e3:71:49:8c:8b:1e:2c:e4:e6:92:85:
d7:ea:0c:77:57:6d:0f:f9:d3:c1:38:86:51:26:af:8e:36:e4:
8f:1c:22:45:1d:cb:95:37:25:f3:6c:ad:b1:c9:82:57:44:40:
c7:cf:23:1b:5c:79:5b:4b:7c:ea:88:da:89:30:fc:45:91:92:
5d:b0:3a:05:8f:fe:c7:4e:6e:7a:72:be:e4:1f:02:9f:85:9f:
99:c3:c8:bc:00:c4:99:82:d2:3c:d6:44:a3:4e:8b:2a:91:24:
b8:d2:df:d1:8d:e8:aa:74:fd:93:b4:96:f8:1a:8e:b8:7d:87:
67:6e:49:57:81:5a:e3:59:78:59:78:e4:4b:e8:ba:f0:41:bc:
af:b6:81:27:28:e5:38:93:66:74:b4:96:4b:45:c4:4c:85:0f:
73:5b:df:00
-----BEGIN CERTIFICATE-----
MIIFRjCCBC6gAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBsDELMAkGA1UEBhMCVVMx
CzAJBgNVBAgTAkNBMRUwEwYDVQQHEwxTYW5GcmFuY2lzY28xGzAZBgNVBAoTEnBy
b1hQTiBEaXJlY3QsIExMQzETMBEGA1UECxMKcHJveHBuLmNvbTETMBEGA1UEAxMK
cHJveHBuLmNvbTETMBEGA1UEKRMKcHJveHBuLmNvbTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBwcm94cG4uY29tMB4XDTEwMDYwODE0NDUxMloXDTIwMDYwNTE0NDUx
MlowgbAxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEVMBMGA1UEBxMMU2FuRnJh
bmNpc2NvMRswGQYDVQQKExJwcm9YUE4gRGlyZWN0LCBMTEMxEzARBgNVBAsTCnBy
b3hwbi5jb20xEzARBgNVBAMTCnByb3hwbi5jb20xEzARBgNVBCkTCnByb3hwbi5j
b20xITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAcHJveHBuLmNvbTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAOCTcOtLanvBLBsn3f1+oRDvlwKT7rSEzqZc
cQMsZu+lIPFL3Eg1aqbSsNjrA/5tbipcl1q8irxa9X2Y1cG41o3GhNUqU0dkEkF9
WMok1Uk1AvTBHab54mLCIQvvxR/H03VmbIl8s4IEKu/98pBcwc4VJTtcR6NZaVt9
WbIgd5JJCsbc90AWPNIf53iHjPexLTK13f9OXSmrEokKdWXjpAobMFpYTaS65gld
D/xHm1Y9gwijmYDT47k9dSa7rS/lm1Sqg4mG63flVadLmGJCmh5SW+fay7nJ6bRo
DAQQy/W8hAgti8bzgapXara/qrv+eX6HZEUhOf3wsrcU7FI63A0CAwEAAaOCAWcw
ggFjMAkGA1UdEwQCMAAwLQYJYIZIAYb4QgENBCAWHkVhc3ktUlNBIEdlbmVyYXRl
ZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUInXdWVEw0deIgKFMmaBJI9gycFswgeUG
A1UdIwSB3TCB2oAUq80kGlC9rEN0jV7HAsHt0lrI+uOhgbakgbMwgbAxCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJDQTEVMBMGA1UEBxMMU2FuRnJhbmNpc2NvMRswGQYD
VQQKExJwcm9YUE4gRGlyZWN0LCBMTEMxEzARBgNVBAsTCnByb3hwbi5jb20xEzAR
BgNVBAMTCnByb3hwbi5jb20xEzARBgNVBCkTCnByb3hwbi5jb20xITAfBgkqhkiG
9w0BCQEWEnN1cHBvcnRAcHJveHBuLmNvbYIJANJevG4eanbDMBMGA1UdJQQMMAoG
CCsGAQUFBwMCMAsGA1UdDwQEAwIHgDANBgkqhkiG9w0BAQUFAAOCAQEAqizcAivA
N6RN04j0rvU6vtOAdo3xhTZ6fuLFZc8JA7H7vRLvyIsYZNeX2UH+ZM7OTugUMGlJ
z9pzFv0b2iOqcZadLajV6hvGjgERSzar0LpOiWaUlH+rRwDzXwBpLsPivuNxSYyL
Hizk5pKF1+oMd1dtD/nTwTiGUSavjjbkjxwiRR3LlTcl82ytscmCV0RAx88jG1x5
W0t86ojaiTD8RZGSXbA6BY/+x05uenK+5B8Cn4WfmcPIvADEmYLSPNZEo06LKpEk
uNLf0Y3oqnT9k7SW+BqOuH2HZ25JV4Fa41l4WXjkS+i68EG8r7aBJyjlOJNmdLSW
S0XETIUPc1vfAA==
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA4JNw60tqe8EsGyfd/X6hEO+XApPutITOplxxAyxm76Ug8Uvc
SDVqptKw2OsD/m1uKlyXWryKvFr1fZjVwbjWjcaE1SpTR2QSQX1YyiTVSTUC9MEd
pvniYsIhC+/FH8fTdWZsiXyzggQq7/3ykFzBzhUlO1xHo1lpW31ZsiB3kkkKxtz3
QBY80h/neIeM97EtMrXd/05dKasSiQp1ZeOkChswWlhNpLrmCV0P/EebVj2DCKOZ
gNPjuT11JrutL+WbVKqDiYbrd+VVp0uYYkKaHlJb59rLucnptGgMBBDL9byECC2L
xvOBqldqtr+qu/55fodkRSE5/fCytxTsUjrcDQIDAQABAoIBACkSjipaZqUvlTN6
PR1plWeVihbMm3GkgG7opTqhWkol9zpqV2VVb6YHDpT9loNn3CgfOwc7SFxeflt0
IlQFzCet0Qlzbju2T6hulliSF/gFm/7LevLY7NCHFKgsN+8yCriD/QHALsxumrO9
zCke7csVDvQmUmvLpHs5F7h+O6AjJ/3WLeZnldKAnO/vePmuvHMsjheqhoWQOkyD
9HOxNy8BIa7JnBnLNAtaHGDtg0kVF6lsteQwKplxBXWxJcEYwHykAjg0kHz0yXy1
KX227SMoW2X2M24k+jm+X9yhGqA1FF/TVoKjbm0Xl3O69N61gQCFMKZHsDcntnUD
5P6D2MECgYEA9OW5y5F/Ws9RncMaFSOFS1iGHENv8Pb1tKpGNRMXQujGQchAIR0+
GRh2k0ULxvzcCZ+FpXkM9wok4+E6Exq7ivySti6LAxJIT+Ki+9CaFItENNwqbr+y
YfNZo6CzR7uZ1u8KjGC3/KzgE9tFnUsIllswfRf0zc5zBtgTkg6k23UCgYEA6sHd
gXG6t5dzL4MDbR//1rSIJyNbk/caWfeUWGxOpWLwBVceOICq8BW3+YLdl6LjRhjY
QSg9iA1hH6FgYVmV2LKOUnSY4EqA/bSgRxMUk4p65ZjgIhswQVeIoMuSq/fYggVH
mTjTe2kRk7M6pf0w15qkfnJo5gmlRyFLNY/RIzkCgYBJvdriV1934rF6xcLW1qlO
dMt9Ozk738FAs30MgkEg3qLEMB5PWlTWja02zzWqp31CUIyXtQmYYa+WBr3L/uK2
CTPMM9ucAydPFrlpBfk/cmgJWrpUOtjl8bbuNHeHhA/gzn3ooz8DkLKwh/hAUtW1
IKRLJqmKRz4Ps4TBGDO/+QKBgQDCPK+a18/m8c+jYyJlmxFiw7LXt0Chd9X81IWQ
d+TGoMr5kDB4DbXhugaj0uyn92VW7V2Y48Otm2xd8Hc/dREv3+U0QjbvdZWu1VG8
HQRsYyr2Z3wjnB1cIyHv8SAlW4dvZRDtrQAGX1PkwmnnR0uvSMuLt/wlQZvX86s3
4QvouQKBgQDl1bEkmAqHj0LHr9YdybYoJX7O8wK5DlTdzYnJcY+DVlStVNbNxqr7
cKBfLqe0NdAPQtcBLkIU/iV91IAozg/6iLklDhPHG1B6o/nYrYf/8Z/1M8HwQCYs
QY+ssFWITze/+4aNyZahx/r+dUSeYQwXHGQul0QIvH1+PGQIuV7vWw==
-----END RSA PRIVATE KEY-----
</key>

[whatsmyusername]

I'm not an expert, but I don't think you want to post your private keys on here - I would blank those out (indicate that this has been done), and you might think about recreating those on your machine, now that they're on the net.

[Timerift]

Thank for the advice. I'll give it a try. Here is what my current config file looks like:

client
remote ios-d2.proxpn.com 443
dev tun
proto tcp
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 4
mute 5
tun-mtu 1500
mssfix 1450
auth-user-pass
reneg-sec 3600

route-method exe
route-delay 1 10
route-metric 512
route 0.0.0.0 0.0.0.0
tls-client

<ca>

</ca>

<cert>
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com/name=proxpn.com/emailAddress=support@proxpn.com
Validity
Not Before: Jun 8 14:45:12 2010 GMT
Not After : Jun 5 14:45:12 2020 GMT
Subject: C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com/name=proxpn.com/emailAddress=support@proxpn.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:e0:93:70:eb:4b:6a:7b:c1:2c:1b:27:dd:fd:7e:
a1:10:ef:97:02:93:ee:b4:84:ce:a6:5c:71:03:2c:
66:ef:a5:20:f1:4b:dc:48:35:6a:a6:d2:b0:d8:eb:
03:fe:6d:6e:2a:5c:97:5a:bc:8a:bc:5a:f5:7d:98:
d5:c1:b8:d6:8d:c6:84:d5:2a:53:47:64:12:41:7d:
58:ca:24:d5:49:35:02:f4:c1:1d:a6:f9:e2:62:c2:
21:0b:ef:c5:1f:c7:d3:75:66:6c:89:7c:b3:82:04:
2a:ef:fd:f2:90:5c:c1:ce:15:25:3b:5c:47:a3:59:
69:5b:7d:59:b2:20:77:92:49:0a:c6:dc:f7:40:16:
3c:d2:1f:e7:78:87:8c:f7:b1:2d:32:b5:dd:ff:4e:
5d:2912:89:0a:75:65:e3:a4:0a:1b:30:5a:58:
4d:a4:ba:e6:09:5d:0f:fc:47:9b:56:3d:83:08:a3:
99:80:d3:e3:b9:3d:75:26:bb:ad:2f:e5:9b:54:aa:
83:89:86:eb:77:e5:55:a7:4b:98:62:42:9a:1e:52:
5b:e7:da:cb:b9:c9:e9:b4:68:0c:04:10:cb:f5:bc:
84:08:2d:8b:c6:f3:81:aa:57:6a:b6:bf:aa:bb:fe:
79:7e:87:64:45:21:39:fd:f0:b2:b7:14:ec:52:3a:
dc:0d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
Easy-RSA Generated Certificate
X509v3 Subject Key Identifier:
22:75:DD:59:51:30:D1:D7:88:80:A1:4C:99:A0:49:23:D8:32:70:5B
X509v3 Authority Key Identifier:
keyid:AB:CD:24:1A:50:BD:AC:43:74:8D:5E:C7:02:C1:ED:D2:5A:C8:FA:E3
DirName:/C=US/ST=CA/L=SanFrancisco/O=proXPN Direct, LLC/OU=proxpn.com/CN=proxpn.com/name=proxpn.com/emailAddress=support@proxpn.com
serial:D2:5E:BC:6E:1E:6A:76:C3

X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature
Signature Algorithm: sha1WithRSAEncryption
aa:2c:dc:02:2b:c0:37:a4:4d:d3:88:f4:ae:f5:3a:be:d3:80:
76:8d:f1:85:36:7a:7e:e2:c5:65:cf:09:03:b1:fb:bd:12:ef:
c8:8b:18:64:d7:97:d9:41:fe:64:ce:ce:4e:e8:14:30:69:49:
cf:da:73:16:fd:1b:da:23:aa:71:96:9d:2d:a8:d5:ea:1b:c6:
8e:01:11:4b:36d0:ba:4e:89:66:94:94:7f47:00:f3:
5f:00:69:2e:c3:e2:be:e3:71:49:8c:8b:1e:2c:e4:e6:92:85:
d7:ea:0c:77:57:6d:0f:f9:d3:c1:38:86:51:26:af:8e:36:e4:
8f:1c:22:45:1d:cb:95:37:25:f3:6c:ad:b1:c9:82:57:44:40:
c7:cf:23:1b:5c:79:5b:4b:7c:ea:88:da:89:30:fc:45:91:92:
5d:b0:3a:05:8f:fe:c7:4e:6e:7a:72:be:e4:1f:02:9f:85:9f:
99:c3:c8:bc:00:c4:99:82:d2:3c:d6:44:a3:4e:8b:2a:91:24:
b8:d2:df:d1:8d:e8:aa:74:fd:93:b4:96:f8:1a:8e:b8:7d:87:
67:6e:49:57:81:5a:e3:59:78:59:78:e4:4b:e8:ba:f0:41:bc:
af:b6:81:27:28:e5:38:93:66:74:b4:96:4b:45:c4:4c:85:0f:
73:5b:df:00

</key>

[Timerift]

I tried what you suggested but that doesn't seem to be working either. As for posting the keys I'm sorry I checked with proxpn and they said unless your a premium user you wouldn't be able use the key. I do use a long random password for getting in.

Back on the problem at hand though I'm noticing now that it seems it might be a problem with 1.02. On my iPhone which before the 1.02 update I could get to things like my sling box and the like I can't now. I was at Burger King and I got on their wifi and I was able to reach my sling box while NOT on using the OPENVPN app but after I connected with the OPENVPN app I couldn't connect to the sling box. I checked safari and went to the Shields up page on GRC.com and I was definitely using the VPN for getting GRC and using ShieldsUp. But now I can't actually get to the sling box while on the VPN which shouldn't happen. I don't think I'm the only person having this problem but I might be noticing it more because my work blocks certain ports which when I'm using OPENVPN on the mac or PC or android doesn't seem to be a problem. And again this problem now seems to be something that actually came with 1.02 since my iPhone 5 (not a 5S) was never having any problems connecting to internet services before that update. I really do feel like OPENVPN is not actually sending ALL traffic through the VPN (just Safari traffic).

[Timerift]

O.k. and now some more evidence. I am at my house where I don't have any restrictions on my wifi at home. When I'm on my home wifi without the VPN I can get on my Slingbox and also get email from Gmail on the mail app. But when I turn on the OPENVPN app I'm not able to get on the Slingbox or get gmail from the Mail App. This is happening on both the iPhone 5 and the iPad Air. There really seems to be something that happend with the 1.02 update.

[Enrico83]

If I am not wrong, the "send all traffic through VPN" in iOS or OSX should affect only traffic that is for an ip that belongs to a different network... So, if you are into a 192.168.1.X /24 network, if you are tryin to connect to a server inside the dest VPN with an ip for example 192.168.1.5 than network traffic won't be forwarded, since belongs to your source network....

So afaik, you will not be able to use VPN hosted ip when they have same network identifier as your...

Hope this helped, and hope a solution will be found since this turns useless most of personal VPN configurations...

Regards,
E

[jamesyonan]

If the server pushes the "redirect-gateway" option (or if you have it hardcoded in your client config file), OpenVPN will essentially tell the iOS VPN Framework to route all traffic through the VPN. This in turn will cause iOS to promote the tunnel adapter ("utun0") to the default gateway. At this point, all network traffic should flow through the VPN.

See attached screenshot of routing table taken from iPad Air running iOS 7. This shows what the routing table should look like when the VPN is connected and "redirect-gateway" is enabled. Note that the utun0 device is the default gateway (screenshot from "System Status" app).

James

[Timerift]

I have tried putting in the redirect-gateway def1 but still I'm not able to get any traffic from any other IP app to use the VPN. On my own home network I can't to my sling box or use gmail in the mail app (it says it can't find imap.gmail.com. Now Safari is definitely going through the VPN (I'm testing that using Shieldsup on GRC.com). If I turn off the VPN then those apps are working. They also work using PPTP. Here is my current config:

client
remote ios-d2.proxpn.com 443
dev tun
proto tcp
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 4
mute 5
tun-mtu 1500
mssfix 1450
auth-user-pass
reneg-sec 3600
redirect-gateway def1

route-method exe
route-delay 1 10
route-metric 512
route 0.0.0.0 0.0.0.0
tls-client

<ca>
-----BEGIN CERTIFICATE-----

Also here is the status I'm getting from the app:

2014-01-02 21:47:37 SSL Handshake: TLSv1.0/TLS-DHE-RSA-WITH-AES-256-CBC-SHA
2014-01-02 21:47:37 Session is ACTIVE
2014-01-02 21:47:38 EVENT: GET_CONFIG
2014-01-02 21:47:38 Sending PUSH_REQUEST to server...
2014-01-02 21:47:38 OPTIONS:
0 [route] [0.0.0.0] [0.0.0.0]
1 [redirect-gateway] [def1]
2 [dhcp-option] [DNS] [8.8.8.8]
3 [dhcp-option] [DNS] [4.2.2.1]
4 [redirect-gateway]
5 [route-gateway] [173.0.11.1]
6 [topology] [subnet]
7 [ping] [10]
8 [ping-restart] [60]
9 [ifconfig] [173.0.11.192] [255.255.255.0]

2014-01-02 21:47:38 LZO-ASYM init swap=0 asym=0
2014-01-02 21:47:38 EVENT: ASSIGN_IP
2014-01-02 21:47:38 Connected via tun
2014-01-02 21:47:38 EVENT: CONNECTED timerift@gmail.com@ios-d2.proxpn.com:443 (107.6.100.21) via /TCPv4 on tun/173.0.11.192/
2014-01-02 21:49:47 EVENT: DISCONNECTED
2014-01-02 21:49:47 Raw stats on disconnect:
BYTES_IN : 50067
BYTES_OUT : 32893
PACKETS_IN : 136
PACKETS_OUT : 202
TUN_BYTES_IN : 23333
TUN_BYTES_OUT : 43083
TUN_PACKETS_IN : 159
TUN_PACKETS_OUT : 138
2014-01-02 21:49:47 Performance stats on disconnect:
CPU usage (microseconds): 288754
Tunnel compression ratio (uplink): 1.40972
Tunnel compression ratio (downlink): 1.16211
Network bytes per CPU second: 287303
Tunnel bytes per CPU second: 230008
2014-01-02 21:49:47 ----- OpenVPN Stop -----

I just don't know where to go from here. This same behavior is happening on my iPhone5 and the Slingbox app was working on it when I was on 1.01. If there is another setting I can tweak let me know and I'll definitely try it. Thanks everyone.

[Enrico83]

Hi all,
so i have this openvpn client configuration:

dev tun
tls-client
remote ****** 1194
float
redirect-gateway #tried both with and without def1
pull
proto udp
script-security 2
ca ca.crt
comp-lzo
reneg-sec 0
auth-user-pass

And i have this log:

2014-01-04 17:32:29 ----- OpenVPN Start (iOS 64-bit) -----
2014-01-04 17:32:29 Keychain Cert Extraction: 1 certificate(s) found
2014-01-04 17:32:29 UNUSED OPTIONS
1 [tls-client]
3 [float]
5 [pull]
7 [script-security] [2]

2014-01-04 17:32:29 LZO-ASYM init swap=0 asym=0
2014-01-04 17:32:29 EVENT: RESOLVE
2014-01-04 17:32:30 Contacting 2.234.68.14:11944 via UDP
2014-01-04 17:32:30 EVENT: WAIT
2014-01-04 17:32:30 Connecting to ecnetwork.synology.me:11944 (2.234.68.14) via UDPv4
2014-01-04 17:32:30 EVENT: CONNECTING
2014-01-04 17:32:30 Tunnel Options:V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client
2014-01-04 17:32:30 Peer Info:
IV_VER=3.0
IV_PLAT=ios
IV_NCP=1
IV_LZO=1

2014-01-04 17:32:30 VERIFY OK: depth=1
cert. version : 3
serial number : 96:A8:73:12:D8:9A:A8:98
issuer name : C=TW, ST=Taiwan, L=Taipei, O=Synology Inc., OU=Certificate Authority, CN=Synology Inc. CA, emailAddress=product@synology.com
subject name : C=TW, ST=Taiwan, L=Taipei, O=Synology Inc., OU=Certificate Authority, CN=Synology Inc. CA, emailAddress=product@synology.com
issued on : 2011-06-28 17:35:48
expires on : 2031-03-15 17:35:48
signed using : RSA+SHA1
RSA key size : 1024 bits

2014-01-04 17:32:30 VERIFY OK: depth=0
cert. version : 3
serial number : 89:EE:C3:AF:4E:3C:F8:29
issuer name : C=TW, ST=Taiwan, L=Taipei, O=Synology Inc., OU=Certificate Authority, CN=Synology Inc. CA, emailAddress=product@synology.com
subject name : C=XY, ST=Snake Desert, L=Snake Town, O=Snake Oil, Ltd, OU=Certificate Authority, CN=Snake Oil CA, emailAddress=ca@snakeoil.dom
issued on : 2011-06-29 00:12:56
expires on : 2031-03-16 00:12:56
signed using : RSA+SHA1
RSA key size : 1024 bits

2014-01-04 17:32:31 SSL Handshake: TLSv1.0/TLS-DHE-RSA-WITH-AES-256-CBC-SHA
2014-01-04 17:32:31 Session is ACTIVE
2014-01-04 17:32:32 EVENT: GET_CONFIG
2014-01-04 17:32:32 Sending PUSH_REQUEST to server...
2014-01-04 17:32:32 OPTIONS:
0 [redirect-gateway]
1 [route] [192.168.1.0] [255.255.255.0]
2 [route] [10.8.0.0] [255.255.255.0]
3 [route] [10.8.0.1]
4 [topology] [net30]
5 [ping] [10]
6 [ping-restart] [60]
7 [ifconfig] [10.8.0.6] [10.8.0.5]

2014-01-04 17:32:32 LZO-ASYM init swap=0 asym=0
2014-01-04 17:32:32 EVENT: ASSIGN_IP
2014-01-04 17:32:32 Connected via tun
2014-01-04 17:32:32 EVENT: CONNECTED vpnuser@ecnetwork.synology.me:11944 (2.234.68.14) via /UDPv4 on tun/10.8.0.6/
2014-01-04 17:34:11 EVENT: DISCONNECTED
2014-01-04 17:34:11 Raw stats on disconnect:
BYTES_IN : 430785
BYTES_OUT : 76582
PACKETS_IN : 521
PACKETS_OUT : 523
TUN_BYTES_IN : 57669
TUN_BYTES_OUT : 412569
TUN_PACKETS_IN : 485
TUN_PACKETS_OUT : 484
2014-01-04 17:34:11 Performance stats on disconnect:
CPU usage (microseconds): 158364
Tunnel compression ratio (uplink): 1.32796
Tunnel compression ratio (downlink): 1.04415
Network bytes per CPU second: 3203802
Tunnel bytes per CPU second: 2969349
2014-01-04 17:34:11 ----- OpenVPN Stop -----


Connection is working, i get new gateway external ip,
but still will not be able to connecto to host with same network number.

Any advice?

Thanks in advance,
E

[StygianAgenda]

[ FYI]
I managed to change the gateway redirect by simply adding

redirect-gateway

to the top of the OVPN file.
Before doing so, however, I copied the ovpn file I planned to use to a new file and performed the edit within the new file.

I've kept the old file, and imported the new one into my Android-x86 USB stick, which is now connecting to my home VPN and routing all traffic through it.

Those of you having trouble with the routing, here's the deal:
You have to specify an otherwise unused subnet at the server, separate from the subnet of the internal network behind the VPN server.

[Example]
VPN-Subnet: 192.168.191.0/25
LAN-Subnet: 172.18.0.0/22

** Clients connect to the WAN address/port of the VPN server, and are issued an IP within the 192.168.191.x subnet. The OVPN server is configured to push a route to the clients of '172.18.0.0/22'. Client traffic then essentially routes through the OVPN server on the initial private subnet to the actual physical subnet. It basically acts like a DMZ subnet.

[nino]

Just to add to this, im having an issue routing all traffic on IOS as well, works fine on PC/OSX

Home LAN is 192.168.1.1/24
VPN LAN is 10.0.0.0/24

Connected to a 172.0.0.1/24 network:
[*][/color]Laptop works
[*][/color]iOS works

Connected to a 192.168.1.1/24 network
[*][/color]Laptop works
[*][/color]iOS does not route traffic/I can hit the servers 10.0.0.1/24 interface and ping the TUN ip.

So for IOS it looks like the redirect-gateway command works as expected on different lans but fails when its the same lan.

StygianAgenda can you post your client/server conf?

[nino]

Actually it looks like the traffic is routing though however I can't access other network resources on the 192.168.1.1/24 network on iOS and when the network is the same. I suspect a routing issue on iOS?


Sent from my iPhone using Tapatalk

[nino]

Actually it looks like the traffic is being routed through the vpn in all of the above senarios.

The issue appears to be accessing other network devices on the LAN, on iOS and the remote LAN is the same as the local.

[StygianAgenda]

(client-conf-file, down to beginning of key-section)

Code: Select all

redirect-gateway
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
remote stormnine.noip.us 1194 udp
lport 0
auth-user-pass
ns-cert-type server
comp-lzo

# dont terminate service process on wrong password, ask again
auth-retry interact
# open management channel
management 127.0.0.1 166
# wait for management to explicitly start connection
management-hold
# query management channel for user/pass
management-query-passwords
# disconnect VPN when management program connection is closed
management-signal
# forget password when management disconnects
management-forget-disconnect

Unfortunately, my server installation doesn't easily allow for export, due to being integrated with pfSense on my router-box. But, my server is basically configured as follows:

Server Mode: Remote Access (User Auth)
Back-end for authentication: Active Directory
protocol: UDP
device mode: TUN
interface: ANY
local port: 1194 (default)
IPv4 Tunnel Network: 192.168.191.0/25
IPv4 Local Networks: 172.18.0.0/22
Concurrent connections: 10
Compression: (checked)
Interclient communications: (checked)

Below that, I have my configuration tying the clients into the addressing structure of my network (DNS, WINS, NTP, NetBIOS type: h-node), and nothing set in the advanced configuration box.

Now, I'm not sure how this conforms to the layout of, for instance, a Win32-openVPN-Server instance, but I figure it should make sense none the less.

Your listing of your home network appears to be incorrect, or else unroutable.
What you have shown: 192.168.1.1/24 <- invalid
What it should be: 192.168.1.0/24 <- valid 24bit subnet in CIDR expression; 253 usable addresses (192.168.1.1-254)

192.168.1.0 is your network address.
192.168.1.1 should be your router address, although your own configuration may place this elsewhere.
192.168.1.255 is the broadcast address of your network, used by TCP/IP for packets belonging to protocols such as ARP that broadcast on UDP to all systems within the subnet.

In my network, I use a 22bit subnet, rather than a 24bit, so I have 1022 usable addresses plus the network address (172.18.0.0) and the broadcast address (172.18.3.255). My router sits at 172.18.0.1, and devices populate other IPs within the 172.18.0.2-255 range. I use the 172.18.1.1-255 range for servers, 172.18.2.1-255 for workstations with static IPs, and 172.18.3.1-254 for dynamically assigned IP-based-clients (VPN, local DHCP, etc).

Now, one thing I'll note here, I haven't done any work with the IOS client other than to create an export of my client config for that platform. But I haven't tested it, and probably won't because I don't/won't use Apple products due to their being too locked down for my tastes as a developer/netadmin/ethical-hacker. I've so far only tested my solution from an Android based client to a pfSense (FreeBSD-Unix) based router and active-directory authenticated intranet. I haven't used stand alone auth, and I have yet to test this solution for Win32/64 or any Linux aside from Android-x86... but that worked perfectly well, even from a USB stick-based-install ran on a work-PC as a quick POC (proof of concept). I suspect that provided that the server-side environment is configured solidly to match your infrastructure, then the client config should work out pretty easily from there so long as it all complies to standards.

[nino]

So it looks like the issue is with the openVPN connect iOS client.

Just to confirm the setup

PRIVATE LAN: 192.168.1.0/24
VPN LAN: 10.8.0.0/24

HOTSPOT LAN: 192.168.1.0/24

The config is set to route all traffic through the VPN and the same ovpn file is used on all test devices.

On Android, PC and OSX traffic is routed and I can access other devices on the private network

On iOS the traffic is routed but I can't access other devices.

So it's not a configuration or networking problem, goes openvpn have a big tracker?

N


Sent from my iPhone using Tapatalk

[Traffic]

PRIVATE LAN: 192.168.1.0/24
VPN LAN: 10.8.0.0/24

HOTSPOT LAN: 192.168.1.0/24

Your private LAN is conflicting with your Hotspot LAN and so routing is broken.

Change your private LAN to something else .. like 192.168.137.0/24

[StygianAgenda]

PRIVATE LAN: 192.168.1.0/24
VPN LAN: 10.8.0.0/24

HOTSPOT LAN: 192.168.1.0/24

Your private LAN is conflicting with your Hotspot LAN and so routing is broken.

Change your private LAN to something else .. like 192.168.137.0/24

Exactly!

[nino]

I appreciate what your saying but why does it work on PC/Android/OSX but not on iOS.