SoftEther: the best VPN: How to set up Client to Site VPN without Port Forward
Once I learned about SoftEther VPN, I realized I was missing out on a lot. In this article I will show you how to setup a Client to Site VPN without needingRead More…
NETGEAR – IPsec VPN Client connect to CISCO Firewall – (Client 2 Box)
The Views Expressed Below Do not in any way reflect Internal Doctorine or Official Statements of Netgear Inc. These are just my notes – Use at your own Risk. The NETGEAR IPSEC VPN ClientRead More…
NETGEAR – IPSEC VPN Client – MAC & Iphone & Ipad – (Client 2 Box)
The Views Expressed Below Do not in any way reflect Internal Doctorine or Official Statements of Netgear Inc. These are just my notes – Use at your own Risk. A quick note onRead More…
NETGEAR – IPSEC VPN CLIENT – (Client 2 Box) – Windows
HOW TO SET UP A CLIENT IPSEC VPN UPDATE: 11/16/2012 The Views Expressed Below Do not in any way reflect Internal Doctorine or Official Statements of Netgear Inc. These are just my notesRead More…
OPENVPN – 3 – Bridged VPN – Static Key – Client 2 Site
Click on the top button to “open code in new window” to see it in a nice format
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 |
OPENVPN – 3 – BRIDGED VPN – STATIC KEY – CLIENT 2 SITE ####################################################### ####################################################### SIMPLEST BRIDGED OPENVPN CONFIG - WITH STATIC KEY ################################################### ################################################### CITATION: http://wiki.openwrt.org/doc/howto/vpn.server.openvpn.tap First generate a key. Then write the openvpn bridge script (start it, and might as well always have it start once per boot) Then write the openvpn server config and start the openvpn server Then copy the key to the client and repeat Then start the server openvpn Then start the client openvpn Both should start no problem although we still cant access anything, you must now add an ip address to the client in the same subnet as the server - make sure its unused NOTE @ THE FIREWALL IN THE NETWORK WHERE THE SERVER (THE ONE BEING THE OPENVPN SERVER) IS AT THERE IS A UDP PORT FORWARD OF PORT 50006 FROM FIREWALL FACING INTERNET TO PORT 50006 UDP ON SERVER (THE ONE BEING THE OPENVPN SERVER) THE ONLY FIREWALL CONFIG I NEEDED AT THE CLIENT WAS A PORTFORWARD TO ACCESS SSH ON THE CLIENT, BUT THATS OPTIONAL THATS JUST SO I HAVE ACCESS TO THE LINUX SHELL FROM ANYWHERE, THE MAIN ONE FOR THIS IS ESSENTIALLY ALLOWING OUTBOUND TRAFFIC OUT AT THE CLIENT NETWORK - THATS TYPICAL FIREWALL DEFAULTS THOUGH ALL ALL OUTBOUND TRAFFIC INSTALLATION ################# ON SERVER: apt-get install bridge-utils apt-get install openvpn apt-get install openssl ON CLIENT: apt-get install openvpn apt-get install openssl GENERATE KEY ################ openvpn --genkey --secret /etc/openvpn/openvpn.key TX KEY TO CLIENT: cat openvpn.key | ssh -p 50005 www.client.com "cat - > /etc/openvpn/openvpn.keykey" SIMPLE OPENVPN BRIDGE ######################## touch /etc/openvpn/openvpnbridge.sh; chmod +x /etc/openvpn/openvpnbridge.sh #!/bin/bash # /etc/openvpn/openvpnbridge.sh # Taken from http://openvpn.net/bridge.html insmod tun br="br0" tap="tap0" for t in $tap; do openvpn --mktun --dev $t done for t in $tap; do brctl addif $br $t done for t in $tap; do ifconfig $t 0.0.0.0 promisc up done OTHER BRIDGE START AND STOP FROM PREVIOUS EXAMPLE WORK, BUT ABOVE LOOKS MORE APPEALING ######################################################################################### Why this one isnt as good? This bridge start stop, enabled the bridge and tap and it switches the ip of eth0 to the bridge/tap where as on the above one it stays on eth... This can happen because they are the same leg, so it doesnt matter especially since they are all promiscous. And the above method doesnt need a stop. OTHER START BRIDGE ====================== At the very bottom/end in OTHER/EXTRA notes section OTHER STOP BRIDGE ==================== At the very bottom/end in OTHER/EXTRA notes section SIMPLE SERVER /etc/openvpn/openvpn.conf ######################################### port 50006 proto udp dev tap0 keepalive 10 120 ;comp-lzo ;persist-key ;persist-tun status openvpn-status.log verb 3 secret /etc/openvpn/openvpn.key SIMPLE CLIENT /etc/openvpn/openvpn.conf ########################################### dev tap0 proto udp remote www.server.com 50006 resolv-retry infinite nobind ;persist-key ;persist-tun # Wireless networks often produce a lot # of duplicate packets. Set this flag # to silence duplicate packet warnings. mute-replay-warnings secret /etc/openvpn/openvpn.key ;comp-lzo verb 3 START ON SERVER ################### service openvpn start It start no problem if you followed above methods START ON CLIENT ################## service openvpn start EXTRA NEEDED THINGS - GET AN IP TO THE CLIENT IN THE SUBNET ============================================================== Both openvpns at the server and client should start no problem although we still cant access anything, you must now add an ip address to the client in the same subnet as the server - make sure its unused ifconfig tap0 172.18.10.160 netmask 255.255.0.0 broadcast 172.18.255.255 OTHER EXTRA NOTES SECTION ################################## IMPORTANT SIDE NOTE: * NOTE IT WORKED FOR ME AND I USED THE BRIDGE FROM BELOW BECAUSE I WAS TOO LAZY TO SWITCH OVER TO THE BETTER/SIMPLER BRIDGE SCRIPT ABOVE. I DIDNT HAVE TO USE ANY FIREWALL IPTABLES (BECAUSE I ALREADY HAVE ALL OPEN NETWORK :-) ) WHAT FILES DID I HAVE IN THE END AT THE SERVER ================================================ If you followed the instructions with the bridge config from above you should have: /etc/openvpn/openvpnbridge.sh <- even though I didnt test this yet, I know this works as the site is credible and users post great things on the comments (what site? the one in citation from above) /etc/openvpn/openvpn.key /etc/openvpn/openvpn.conf If you followed the same instructions but using the bridge below (in OTHER EXTRA NOTES section) instead, which is actually what I ended up doing during the writing of this article: /etc/openvpn/openvpnbridge.sh /etc/openvpn/openvpn.key /etc/openvpn/openvpn.conf WHAT FILES DID I HAVE IN THE END AT THE SERVER ================================================ /etc/openvpn/openvpn.key <-- this is the same as the file @ the server /etc/openvpn/openvpn.conf HOW TO START SERVER WITH BOOT ================================= #!/bin/sh #/etc/init.d/S46openvpn <-- make this file with this in it /etc/openvpn/openvpnbridge.sh openvpn /etc/openvpn/openvpn.conf & OR if S##openvpn already exists then find the append_param() function and add into it: /etc/openvpn/openvpnbridge.sh ANOTHER WAY TO START CONFIGS ================================ Name them other names and launch like this openvpn [config filename here] ANOTHER BRIDGE AND SOME OTHER THINGS TO CONSIDER ==================================================== cd /etc/openvpn touch start.sh; chmod +x start.sh; touch stop.sh; chmod +x stop.sh; MY /etc/openvpn/start.sh --------------------------- #!/bin/bash br="br0" # Define Bridge Interface tap="tap0" # Define list of TAP example tap="tap0 tap1 tap2" eth="eth0" # * CHANGE FROM HERE DOWN eth_ip="172.18.10.21" eth_netmask="255.255.0.0" eth_broadcast="172.18.255.255" eth_gw="172.18.10.2" # * CHANGE FROM HERE UP AND NOTHING BELOW for t in $tap; do openvpn --mktun --dev $t done brctl addbr $br brctl addif $br $eth for t in $tap; do brctl addif $br $t done for t in $tap; do ifconfig $t 0.0.0.0 promisc up done ifconfig $eth 0.0.0.0 promisc up ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast route add default gw $eth_gw $br echo "* Bridge STARTED `date`" >> /var/log/syslog MY /etc/openvpn/stop.sh ----------------------------- #!/bin/bash br="br0" tap="tap0" # * CHANGE FROM HERE DOWN eth="eth0" eth_ip="172.18.10.21" eth_netmask="255.255.0.0" eth_broadcast="172.18.255.255" eth_gw="172.18.10.2" # * CHANGE FROM HERE UP AND NOTHING BELOW ifconfig $br down brctl delbr $br for t in $tap; do openvpn --rmtun --dev $t done ifconfig eth0 -promisc ifconfig $eth $eth_ip netmask $eth_netmask broadcast $eth_broadcast route add default gw $eth_gw $eth echo "* Bridge STOPPED `date`" >> /var/log/syslog TEST THE BRIDGE ----------------------- The bridge should be able to get started and start a ping, you might get disconnected for a second ./start.sh; ping 8.8.8.8 ./stop.sh; ping 8.8.8.8 You should be able to do the above all day long, note its okay if there is a delay after you start the bridge with start.sh and the pings comeing through, sometimes it took me 10 seconds, and sometimes its instant Note when you start the bridge on the server your ifconfig should look like this: ./start.sh ifconfig And when you stop the bridge on the server your ifconfig should look like this: ./stop.sh ifconfig OUTPUT: br0 Link encap:Ethernet HWaddr 00:50:56:aa:cc:44 inet addr:172.18.10.21 Bcast:172.18.10.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:feaa:cc44/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:226268724 errors:0 dropped:40 overruns:0 frame:0 TX packets:72419607 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:128122219579 (119.3 GiB) TX bytes:38122071147 (35.5 GiB) eth0 Link encap:Ethernet HWaddr 00:50:56:aa:cc:44 inet6 addr: fe80::250:56ff:feaa:cc44/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:4785785867 errors:0 dropped:624 overruns:0 frame:0 TX packets:911487819 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3251376854369 (2.9 TiB) TX bytes:967950374803 (901.4 GiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:408 (408.0 B) TX bytes:408 (408.0 B) tap0 Link encap:Ethernet HWaddr a6:0a:c1:be:20:e5 inet6 addr: fe80::a40a:c1ff:febe:20e5/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:14557 errors:0 dropped:0 overruns:0 frame:0 TX packets:69436125 errors:0 dropped:140650466 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1047354 (1022.8 KiB) TX bytes:32999262636 (30.7 GiB) Before continuing start the bridge ./start.sh ifconfig OUTPUT: eth0 Link encap:Ethernet HWaddr 00:50:56:aa:cc:44 inet addr:172.18.10.21 Bcast:172.18.10.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:feaa:cc44/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4786738468 errors:0 dropped:624 overruns:0 frame:0 TX packets:911566372 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3251996200507 (2.9 TiB) TX bytes:967991077500 (901.5 GiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:408 (408.0 B) TX bytes:408 (408.0 B) OTHER CONFIGS: ============== 1. If your server is on an ESXi Server make sure to allow that NIC to have Promiscous mode enabled, for more on that look below If you are setting up the server as a virtual machine, in a ESXi server there is a nasty little gotcha on the network card settings that needs to be changed. The setting is in the VMWare ESX Management Client, then in Networking/Properties/Choose The VLAN your server is using/Edit/Security/Promiscous Mode/Check the box and choose Enable. Otherwise the bridge wont work because the ESX is preventing it from going into promiscous mode. vSphere 5.0 -> Home -> Inventory -> Hosts and Clusters -> select HOST 172.18.10.200 -> Configuration Tab -> Networking -> select Properties for vSwitch that has your machine VSWITCH2 PHYSICAL ADDRESS vmnic4 -> From List select vSwitch and hit edit (((notice there are 2 enteries a vSwitch - which has a summary in the tree of "120 Ports" and a Network "Core Lab Network", editing the vSwitch affects the Network called "Core Lab Network" - which has the summary in the tree of "Virtual Machine Port Group"))) -> Security Tab -> Promiscous Mode -> Change to Accept from Reject (((There shouldnt be a checkbox you have to check to change this, unless you selected the Network/"Virtual Machine Port Group" instead of the correct selection which is the vSwitch))) 2. If you have firewall rules setup with IPTABLES other then allow all then allow the correct packets to passthrough Note with no iptables rules, or just the default Allow All, everything should work: iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination But if you have more vigourous security make sure you run these commands to allow br0 and tap0 to communicate: iptables -A INPUT -i tap0 -j ACCEPT iptables -A INPUT -i br0 -j ACCEPT iptables -A FORWARD -i br0 -j ACCEPT I dont think applies here but maybe this might help, so your troubleshooting you can put this in: echo 1 > /proc/sys/net/ipv4/ip_forward For me it worked with that on "echo 1" and off "echo 0" |
OPENVPN – 2 – Bridged VPN – SSL Certs – Client 2 Site
Click on the top button to “open code in new window” to see it in a nice format
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 |
OPENVPN - 2 - BRIDGED VPN - SSL CERTS - CLIENT 2 SITE ###################################################### ###################################################### OPENVPN BRIDGE VPN WITH SSL/TLS PKI SECURITY ############################################ ############################################ Setting up a OpenVPN configuration from a Debian Server to a Debian Client. The Server is behind a firewall which has a port forward of port 50006 UDP to port 50006 UDP on the server, which gives it that needed UDP port. Note its better to use UDP for vpns as TCP over TCP tends to not work that well. Also as a sidenote you will see port 50006 udp which is portforwarded at server www.server.com to the debian linux server behind the router (the router being the stronghold for www.server.com). You will also see port 50005 which is the tcp for ssh to access the client, so to clarify on my client network, www.client.com, there is a portforward setup on the router there that forward port 50005 tcp to 22 tcp on the debian client machine there. TOPOLOGY: <DEBIAN SERVER 172.18.10.21 /24>-[LAN 172.18.10.x]-[ROUTER www.server.com]========[internet========[ROUTER www.client.com]-[LAN 10.11.12.x]-<DEBIAN CLIENT 10.11.12.55 /24> Note the debian server is actually sits on a vm which comes into play later on, the client is also a vm but that doesnt matter. INSTALLATION: ############### First before continuing install the following software on the server and the client, and make sure you have a putty/shell open for the server and client for easy navigation and inputing of commands. ON SERVER: apt-get install bridge-utils apt-get install openvpn apt-get install openssl ON CLIENT: apt-get install openvpn apt-get install openssl ON SERVER WE NEED TO MAKE THE BRIDGE START AND BRIDGE STOP SCRIPTS ################################################################### cd /etc/openvpn touch start.sh; chmod +x start.sh; touch stop.sh; chmod +x stop.sh; MY /etc/openvpn/start.sh ========================= #!/bin/bash br="br0" # Define Bridge Interface tap="tap0" # Define list of TAP example tap="tap0 tap1 tap2" eth="eth0" # * CHANGE FROM HERE DOWN eth_ip="172.18.10.21" eth_netmask="255.255.255.0" eth_broadcast="172.18.10.255" eth_gw="172.18.10.2" # * CHANGE FROM HERE UP AND NOTHING BELOW for t in $tap; do openvpn --mktun --dev $t done brctl addbr $br brctl addif $br $eth for t in $tap; do brctl addif $br $t done for t in $tap; do ifconfig $t 0.0.0.0 promisc up done ifconfig $eth 0.0.0.0 promisc up ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast route add default gw $eth_gw $br echo "* Bridge STARTED `date`" >> /var/log/syslog MY /etc/openvpn/stop.sh ======================== #!/bin/bash br="br0" tap="tap0" # * CHANGE FROM HERE DOWN eth="eth0" eth_ip="172.18.10.21" eth_netmask="255.255.255.0" eth_broadcast="172.18.10.255" eth_gw="172.18.10.2" # * CHANGE FROM HERE UP AND NOTHING BELOW ifconfig $br down brctl delbr $br for t in $tap; do openvpn --rmtun --dev $t done ifconfig eth0 -promisc ifconfig $eth $eth_ip netmask $eth_netmask broadcast $eth_broadcast route add default gw $eth_gw $eth echo "* Bridge STOPPED `date`" >> /var/log/syslog TEST THE BRIDGE =============== The bridge should be able to get started and start a ping, you might get disconnected for a second ./start.sh; ping 8.8.8.8 ./stop.sh; ping 8.8.8.8 You should be able to do the above all day long, note its okay if there is a delay after you start the bridge with start.sh and the pings comeing through, sometimes it took me 10 seconds, and sometimes its instant Note when you start the bridge on the server your ifconfig should look like this: ./start.sh ifconfig And when you stop the bridge on the server your ifconfig should look like this: ./stop.sh ifconfig OUTPUT: br0 Link encap:Ethernet HWaddr 00:50:56:aa:cc:44 inet addr:172.18.10.21 Bcast:172.18.10.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:feaa:cc44/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:226268724 errors:0 dropped:40 overruns:0 frame:0 TX packets:72419607 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:128122219579 (119.3 GiB) TX bytes:38122071147 (35.5 GiB) eth0 Link encap:Ethernet HWaddr 00:50:56:aa:cc:44 inet6 addr: fe80::250:56ff:feaa:cc44/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:4785785867 errors:0 dropped:624 overruns:0 frame:0 TX packets:911487819 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3251376854369 (2.9 TiB) TX bytes:967950374803 (901.4 GiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:408 (408.0 B) TX bytes:408 (408.0 B) tap0 Link encap:Ethernet HWaddr a6:0a:c1:be:20:e5 inet6 addr: fe80::a40a:c1ff:febe:20e5/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:14557 errors:0 dropped:0 overruns:0 frame:0 TX packets:69436125 errors:0 dropped:140650466 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1047354 (1022.8 KiB) TX bytes:32999262636 (30.7 GiB) Before continuing start the bridge ./start.sh ifconfig OUTPUT: eth0 Link encap:Ethernet HWaddr 00:50:56:aa:cc:44 inet addr:172.18.10.21 Bcast:172.18.10.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:feaa:cc44/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4786738468 errors:0 dropped:624 overruns:0 frame:0 TX packets:911566372 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3251996200507 (2.9 TiB) TX bytes:967991077500 (901.5 GiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:408 (408.0 B) TX bytes:408 (408.0 B) OTHER CONFIGS: 1. If your server is on an ESXi Server make sure to allow that NIC to have Promiscous mode enabled, for more on that look below If you are setting up the server as a virtual machine, in a ESXi server there is a nasty little gotcha on the network card settings that needs to be changed. The setting is in the VMWare ESX Management Client, then in Networking/Properties/Choose The VLAN your server is using/Edit/Security/Promiscous Mode/Check the box and choose Enable. Otherwise the bridge wont work because the ESX is preventing it from going into promiscous mode. vSphere 5.0 -> Home -> Inventory -> Hosts and Clusters -> select HOST 172.18.10.100 where the Server is -> Configuration Tab -> Networking -> select Properties for vSwitch that has your machine VSWITCH2 PHYSICAL ADDRESS vmnic4 -> From List select vSwitch and hit edit (((notice there are 2 enteries a vSwitch - which has a summary in the tree of "120 Ports" and a Network "Lab 1 Network", editing the vSwitch affects the Network called "Lab 1 Network" - which has the summary in the tree of "Virtual Machine Port Group"))) -> Security Tab -> Promiscous Mode -> Change to Accept from Reject (((There shouldnt be a checkbox you have to check to change this, unless you selected the Network/"Virtual Machine Port Group" instead of the correct selection which is the vSwitch))) 2. If you have firewall rules setup with IPTABLES other then allow all then allow the correct packets to passthrough Note with no iptables rules, or just the default Allow All, everything should work: iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination But if you have more vigourous security make sure you run these commands to allow br0 and tap0 to communicate: iptables -A INPUT -i tap0 -j ACCEPT iptables -A INPUT -i br0 -j ACCEPT iptables -A FORWARD -i br0 -j ACCEPT I dont think applies here but maybe this might help, so your troubleshooting you can put this in: echo 1 > /proc/sys/net/ipv4/ip_forward For me it worked with that on "echo 1" and off "echo 0" OPENVPN CONFIGURATION ON THE SERVER ################################### HOW 2 GEN SSL KEYS =================== First move the appropriate template over: cd /etc/openvpn cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/ . -R cd /etc/openvpn/2.0 Empty the file because we will use my template below: :>vars Edit the vars file, and paste the vars template I have below into it, just change the section that says you need to change: nano vars Run the vars file: source vars Prepare to generate the keys: ./clean-all *** IMPORTANT *** NOTE WHEN GENERATING THESE KEYS MOST OF THE ANSWERS SUFFICE A SIMPLE enter KEY PRESS, PUT THE LAST 2 QUESTIONS REQUIRE A y OR n FOR yes OR no: MAKE SURE TO PUT y FOR yes THE QUESTIONS ARE: Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y *** END OF IMPORTANT *** Build the keys: ./build-ca ./build-key-server server ./build-key client ./build-dh Note for additional clients just rerun the ./build-key client and change client to name of the client for example ./build-key bob, afterwards client config changes would have to reflect that change (but thats only 2 lines to change in the client openvpn.conf which you will see later on in this article) Lets copy the needed server keys from where they are at now: /etc/openvpn/2.0/keys to: /etc/openvpn - note that the /etc/openvpn/2.0/keys directory is new - it was generated with the above scripts: cd /etc/openvpn/2.0/keys cp ca.key ca.crt server.crt server.key dh2048.pem /etc/openvpn NOTE: Note in my case it was dh2048.pem in your case it could be dh1024.pem, it depends on if you changed the key strength in the vars file, I didnt so its 2048 for me. So now you should have 5 files in /etc/openvpn: ca.key ca.crt server.crt server.key dh2048.pem, confirm that: ls -lisah /etc/openvpn SERVER /etc/openvpn/openvpn.conf: ==================================== port 50006 proto udp dev tap0 server-bridge 172.18.10.21 255.255.255.0 172.18.10.150 172.18.10.170 keepalive 10 120 persist-key persist-tun ca ca.crt cert server.crt key server.key dh dh2048.pem cipher AES-128-CBC auth MD5 status openvpn-status.log verb 5 START VPN ON SERVER: ==================== service openvpn start If you need to stop the vpn: service openvpn stop If you experience issues check out the /etc/openvpn-status.log and also the syslog /var/log/syslog towards the bottom and start googling. FROM SERVER COPY THE CLIENT KEYS TO CLIENT =========================================== The client needs the following files: 1. ca.crt (he doesnt need the ca.key thats for the server only, or actually for the root authority only, but since we are the root authority in these examples withour self generated keys, then the server is the only one that should have the ca.key) 2. client.crt 3. client.key Note no need to copy the dh2048.pem file, the diffiehelman is also kept on the server So from the server you can copy the 3 files with cat & ssh like this. First go to the folder where all the keys are at - remember we only put the server important keys directly on /etc/openvpn: cd /etc/openvpn/2.0/keys cat ca.crt | ssh www.client.com -p 50005 "cat - > /etc/openvpn/ca.crt" cat client.crt | ssh www.client.com -p 50005 "cat - > /etc/openvpn/client.crt" cat client.key | ssh www.client.com -p 50005 "cat - > /etc/openvpn/client.key" It will ask for the password on each ssh command and also note that the client needs to have the /etc/openvpn folder there for it to copy those files (that folder gets automatically made when you install openvpn with apt-get install openvpn). OPENVPN CONFIGURATION ON THE CLIENT ################################### Now on your client we just make this file. CLIENT /etc/openvpn/openvpn.conf: ==================================== client remote www.server.com port 50006 proto udp dev tap0 persist-key persist-tun pull ca ca.crt cert client.crt key client.key cipher AES-128-CBC auth MD5 verb 5 START VPN ON CLIENT: ==================== service openvpn start If you need to stop the vpn: service openvpn stop If you experience issues check out the /etc/openvpn-status.log and also the syslog /var/log/syslog towards the bottom and start googling. TESTS ###### Try pinging the server first 172.18.10.21 then beyond it, everything should work if not. Google :-) FOR THE FUTURE: ############### In the future to properly start the server: /etc/openvpn/start.sh service openvpn start To properly stop the server service openvpn stop /etc/openvpn/stop.sh It would be nice to make that all automated, and we can, I just didnt include it in this article... Maybe I will as an update later on. VARS - used when making the keys ################################## # MODIFIED FROM:https://github.com/OpenVPN/easy-rsa/blob/master/easy-rsa/2.0/vars # easy-rsa parameter settings # NOTE: If you installed from an RPM, # don't edit this file in place in # /usr/share/openvpn/easy-rsa -- # instead, you should copy the whole # easy-rsa directory to another location # (such as /etc/openvpn) so that your # edits will not be wiped out by a future # OpenVPN package upgrade. # This variable should point to # the top level of the easy-rsa # tree. export EASY_RSA="/etc/openvpn/2.0" # # This variable should point to # the requested executables # export OPENSSL="openssl" export PKCS11TOOL="pkcs11-tool" export GREP="grep" # This variable should point to # the openssl.cnf file included # with easy-rsa. export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA` # Edit this variable to point to # your soon-to-be-created key # directory. # # WARNING: clean-all will do # a rm -rf on this directory # so make sure you define # it correctly! export KEY_DIR="$EASY_RSA/keys" # Issue rm -rf warning echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR # PKCS11 fixes export PKCS11_MODULE_PATH="dummy" export PKCS11_PIN="dummy" # Increase this to 2048 if you # are paranoid. This will slow # down TLS negotiation performance # as well as the one-time DH parms # generation process. export KEY_SIZE=2048 # In how many days should the root CA key expire? export CA_EXPIRE=3650 # In how many days should certificates expire? export KEY_EXPIRE=3650 # These are the default values for fields # which will be placed in the certificate. # Don't leave any of these fields blank. # # ****** CHANGE FROM HERE DOWN ****** # export KEY_COUNTRY="US" export KEY_PROVINCE="CA" export KEY_CITY="SanJose" export KEY_ORG="SERVAWE" export KEY_EMAIL="thisawesome@gmail.com" export KEY_OU="SERVAWELAB" # X509 Subject Field export KEY_NAME="SERVAWE" # # ****** CHANGE FROM HERE UP ****** # # PKCS11 Smart Card # export PKCS11_MODULE_PATH="/usr/lib/changeme.so" # export PKCS11_PIN=1234 # If you'd like to sign all keys with the same Common Name, uncomment the KEY_CN export below # You will also need to make sure your OpenVPN server config has the duplicate-cn option set # export KEY_CN="CommonName" EXTRA EXTRA ########### Some good reading: ================== http://coderazzi.net/howto/openwrt/tl841n/openvpn-bridge.htm http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html Another persons start and stop bridge scripts: =============================================== START BRIDGE: stop ifconfig tap0 &> /dev/null || sleep 1 ifconfig tap0 &> /dev/null || sleep 1 ifconfig tap0 &> /dev/null || sleep 1 fconfig tap0 &> /dev/null || sleep 1 ifconfig tap0 &> /dev/null || sleep 1 brctl addbr br0 brctl addif br0 tap0 brctl addif br0 eth1.2 ifconfig br0 up STOP BRIDGE: ifconfig br0 &> /dev/null || return ifconfig br0 down rctl delbr br0 Some thoughs on the firewall: ============================== For me this worked: # iptables -S default: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT But it recommended this: -A INPUT -i tap0 -j ACCEPT -A INPUT -i br0 -j ACCEPT -A FORWARD -i br0 -j ACCEPT However I also thought this might be needed: -A FORWARD -i tap0 -j ACCEPT -A FORWARD -i eth0 -j ACCEPT Remember to do this: echo 1 > /proc/sys/net/ipv4/ip_forward What does that do? The '1' in "/proc/sys/net/ipv4/ip_forward" enables IP forwarding. A '0' signifies IP forwarding is disabled. Before you issue the echo... command, try cat /proc/sys/net/ipv4/ip_forward and you will see a '0'. You can add echo "1" > /proc/sys/net/ipv4/ip_forward to one of your startup files if you need this enabled all the time. Add to the end of /etc/rc.d/rc.local. There is no portforwarding here so I believe this is more for the topic of routed openvpn. Because after all with extra routes inplace on the server and the lan machines in the servers network you can have the client be able to access all of the servers network with a routed openvpn setup DHCP? ====== So the server-bridge command takes care of it, but if you want more options or have another dhcp server thats also possible. Here is an exerpt from the web. A: want to set up an ethernet bridge on the 192.168.1.0/24 subnet. existing DHCP. Q: I want to set up an ethernet bridge on the 192.168.1.0/24 subnet. How do I configure OpenVPN so that it will cooperate with the existing DHCP server on the LAN? There are two ways to do this. Using the server-bridge directive is the easiest. First, set aside an address pool in your 192.168.1.0/24 subnet for use by OpenVPN clients. This range must be separate from the DHCP server range used on the subnet. Suppose you want OpenVPN to use192.168.1.200 to 192.168.1.254 for allocation to connecting clients, and that the gateway for the LAN is 192.168.1.1. Then the appropriateserver-bridge directive would be: server-bridge 192.168.1.1 255.255.255.0 192.168.1.200 192.168.1.254 In the second method, the OpenVPN clients get their IP address lease from the DHCP server which is serving the LAN. For this configuration, you don't need a server-bridge directive, just something like: mode server dev tap0 # must be bridged with LAN ethernet interface [SSL/TLS parms] [keepalive parms] The clients will negotiate a DHCP lease through the tunnel, meaning that both VPN clients and local machines will receive their IP addresses from the DHCP server address pool. The one complexity about this configuration is that you need to modify your DHCP server configuration to differentiate between local clients and VPN clients. The reason for this is that you must not pass out a default gateway to VPN clients. See the Win32 install notes for an example. SIDE NOTE: STATIC KEY BRIDGE DOESNT WORK WITH SERVER-BRIDGE COMMAND =================================================================== So originally I tried to do this but the syslog told me server-bridge and static key dont work well, so I moved on to making a TLS bridge config. But here are my notes for the none working OPENVPN BRIDGED with STATIC KEY With only a few changes like removing the server-bridge part this could possibly work. Perhaps in a future update Ill include a way to setup Openvpn with bridge with a static key. TO MAKE KEY: openvpn --genkey --secret static.key SERVER FILES: /etc/openvpn/static.key /etc/openvpn/openvpn.conf SERVER OPENVPN.CONF - /etc/openvpn/openvpn.conf: port 50006 proto udp dev tap0 # ifconfig 10.99.99.1 10.99.99.2 server-bridge 10.11.12.55 255.255.255.0 10.11.12.70 10.11.12.80 keepalive 10 120 persist-key persist-tun verb 5 CLIENT FILES: /etc/openvpn/static.key /etc/openvpn/openvpn.conf CLIENT OPENVPN.CONF - /etc/openvpn/openvpn.con: remote www.server.com proto udp port 50006 dev tap pull # ifconfig 10.99.99.2 10.99.99.1 secret static.key A COPY OF THE ENTIRE OPEN VPN MAN PAGE: ======================================== Sign in Follow us Home VPN Service Your Private Tunnel to the Internet VPN Solution Overview Software Packages Virtual Appliances Cloud Machines Purchase License My Licenses Pricing Documentation Quick Start Guide HOWTO Videos Admin Guide Data Sheet FAQ Advantages Community Overview Downloads Source Code Documentation HOWTO Security Overview Examples Graphical User Interface Manuals Change Log Installation Notes Release Notes Miscellaneous Non-English File Signatures Articles FAQ Books Wiki/Tracker Forums Contributing Downloads Access Server Downloads Community Downloads Community Overview Downloads Source Code Documentation HOWTO Security Overview Examples Graphical User Interface Manuals Change Log Installation Notes Release Notes Miscellaneous Non-English File Signatures Articles FAQ Books Wiki/Tracker Forums Contributing OpenVPN 2.0.x NAME openvpn - secure IP tunnel daemon. f SYNOPSIS openvpn [ --help ] openvpn [ --config file ] openvpn [ --genkey ] [ --secret file ] openvpn [ --mktun ] [ --rmtun ] [ --dev tunX | tapX ] [ --dev-type device-type ] [ --dev-node node ] openvpn [ --test-crypto ] [ --secret file ] [ --auth alg ] [ --cipher alg ] [ --engine ] [ --keysize n ] [ --no-replay ] [ --no-iv ] openvpn [ --askpass [file] ] [ --auth-nocache ] [ --auth-retry type ] [ --auth-user-pass-verify script ] [ --auth-user-pass up ] [ --auth alg ] [ --bcast-buffers n ] [ --ca file ] [ --ccd-exclusive ] [ --cd dir ] [ --cert file ] [ --chroot dir ] [ --cipher alg ] [ --client-cert-not-required ] [ --client-config-dir dir ] [ --client-connect script ] [ --client-disconnect ] [ --client-to-client ] [ --client ] [ --comp-lzo ] [ --comp-noadapt ] [ --config file ] [ --connect-freq n sec ] [ --connect-retry n ] [ --crl-verify crl ] [ --cryptoapicert select-string ] [ --daemon [progname] ] [ --dev-node node ] [ --dev-type device-type ] [ --dev tunX | tapX | null ] [ --dev tunX | tapX ] [ --dh file ] [ --dhcp-option type [parm] ] [ --dhcp-release ] [ --dhcp-renew ] [ --disable-occ ] [ --disable ] [ --down-pre ] [ --down cmd ] [ --duplicate-cn ] [ --echo [parms...] ] [ --engine [engine-name] ] [ --explicit-exit-notify [n] ] [ --fast-io ] [ --float ] [ --fragment max ] [ --genkey ] [ --group group ] [ --hand-window n ] [ --hash-size r v ] [ --help ] [ --http-proxy-option type [parm] ] [ --http-proxy-retry ] [ --http-proxy-timeout n ] [ --http-proxy server port [authfile] [auth-method] ] [ --ifconfig-noexec ] [ --ifconfig-nowarn ] [ --ifconfig-pool-linear ] [ --ifconfig-pool-persist file [seconds] ] [ --ifconfig-pool start-IP end-IP [netmask] ] [ --ifconfig-push local remote-netmask ] [ --ifconfig l rn ] [ --inactive n ] [ --inetd [wait|nowait] [progname] ] [ --ip-win32 method ] [ --ipchange cmd ] [ --iroute network [netmask] ] [ --keepalive n m ] [ --key-method m ] [ --key file ] [ --keysize n ] [ --learn-address cmd ] [ --link-mtu n ] [ --local host ] [ --log-append file ] [ --log file ] [ --suppress-timestamps ] [ --lport port ] [ --management-hold ] [ --management-log-cache n ] [ --management-query-passwords ] [ --management IP port [pw-file] ] [ --max-clients n ] [ --max-routes-per-client n ] [ --mktun ] [ --mlock ] [ --mode m ] [ --mssfix max ] [ --mtu-disc type ] [ --mtu-test ] [ --mute-replay-warnings ] [ --mute n ] [ --nice n ] [ --no-iv ] [ --no-replay ] [ --nobind ] [ --ns-cert-type client|server ] [ --passtos ] [ --pause-exit ] [ --persist-key ] [ --persist-local-ip ] [ --persist-remote-ip ] [ --persist-tun ] [ --ping-exit n ] [ --ping-restart n ] [ --ping-timer-rem ] [ --ping n ] [ --pkcs12 file ] [ --plugin module-pathname init-string ] [ --port port ] [ --proto p ] [ --pull ] [ --push-reset ] [ --push "option" ] [ --rcvbuf size ] [ --redirect-gateway ["local"] ["def1"] ] [ --remap-usr1 signal ] [ --remote-random ] [ --remote host [port] ] [ --reneg-bytes n ] [ --reneg-pkts n ] [ --reneg-sec n ] [ --replay-persist file ] [ --replay-window n [t] ] [ --resolv-retry n ] [ --rmtun ] [ --route-delay [n] [w] ] [ --route-gateway gw ] [ --route-method m ] [ --route-noexec ] [ --route-up cmd ] [ --route network [netmask] [gateway] [metric] ] [ --rport port ] [ --secret file [direction] ] [ --secret file ] [ --server-bridge gateway netmask pool-start-IP pool-end-IP ] [ --server network netmask ] [ --service exit-event [0|1] ] [ --setenv name value ] [ --shaper n ] [ --show-adapters ] [ --show-ciphers ] [ --show-digests ] [ --show-engines ] [ --show-net-up ] [ --show-net ] [ --show-tls ] [ --show-valid-subnets ] [ --single-session ] [ --sndbuf size ] [ --socks-proxy-retry ] [ --socks-proxy server [port] ] [ --status file [n] ] [ --status-version n ] [ --syslog [progname] ] [ --tap-sleep n ] [ --tcp-queue-limit n ] [ --test-crypto ] [ --tls-auth file [direction] ] [ --tls-cipher l ] [ --tls-client ] [ --tls-exit ] [ --tls-remote x509name ] [ --tls-server ] [ --tls-timeout n ] [ --tls-verify cmd ] [ --tmp-dir dir ] [ --tran-window n ] [ --tun-ipv6 ] [ --tun-mtu-extra n ] [ --tun-mtu n ] [ --txqueuelen n ] [ --up-delay ] [ --up-restart ] [ --up cmd ] [ --user user ] [ --username-as-common-name ] [ --verb n ] [ --writepid file ] INTRODUCTION OpenVPN is an open source VPN daemon by James Yonan. Because OpenVPN tries to be a universal VPN tool offering a great deal of flexibility, there are a lot of options on this manual page. If you're new to OpenVPN, you might want to skip ahead to the examples section where you will see how to construct simple VPNs on the command line without even needing a configuration file. Also note that there's more documentation and examples on the OpenVPN web site: http://openvpn.net/ And if you would like to see a shorter version of this manual, see the openvpn usage message which can be obtained by running openvpn without any parameters. DESCRIPTION OpenVPN is a robust and highly flexible VPN daemon. OpenVPN supports SSL/TLS security, ethernet bridging, TCP or UDP tunnel transport through proxies or NAT, support for dynamic IP addresses and DHCP, scalability to hundreds or thousands of users, and portability to most major OS platforms. OpenVPN is tightly bound to the OpenSSL library, and derives much of its crypto capabilities from it. OpenVPN supports conventional encryption using a pre-shared secret key (Static Key mode) or public key security (SSL/TLS mode) using client & server certificates. OpenVPN also supports non-encrypted TCP/UDP tunnels. OpenVPN is designed to work with the TUN/TAP virtual networking interface that exists on most platforms. Overall, OpenVPN aims to offer many of the key features of IPSec but with a relatively lightweight footprint. OPTIONS OpenVPN allows any option to be placed either on the command line or in a configuration file. Though all command line options are preceded by a double-leading-dash ("--"), this prefix can be removed when an option is placed in a configuration file. --help Show options. --config file Load additional config options from file where each line corresponds to one command line option, but with the leading '--' removed. If --config file is the only option to the openvpn command, the --config can be removed, and the command can be given as openvpn file Note that configuration files can be nested to a reasonable depth. Double quotation characters ("") can be used to enclose single parameters containing whitespace, and "#" or ";" characters in the first column can be used to denote comments. Note that OpenVPN 2.0 and higher performs backslash-based shell escaping, so the following mappings should be observed: \\ Maps to a single backslash character (\). \" Pass a literal doublequote character ("), don't interpret it as enclosing a parameter. \[SPACE] Pass a literal space or tab character, don't interpret it as a parameter delimiter. For example on Windows, use double backslashes to represent pathnames: secret "c:\\OpenVPN\\secret.key" For examples of configuration files, see http://openvpn.net/examples.html Here is an example configuration file: # # Sample OpenVPN configuration file for # using a pre-shared static key. # # '#' or ';' may be used to delimit comments. # Use a dynamic tun device. dev tun # Our remote peer remote mypeer.mydomain # 10.1.0.1 is our local VPN endpoint # 10.1.0.2 is our remote VPN endpoint ifconfig 10.1.0.1 10.1.0.2 # Our pre-shared static key secret static.key Tunnel Options: --mode m Set OpenVPN major mode. By default, OpenVPN runs in point-to-point mode ("p2p"). OpenVPN 2.0 introduces a new mode ("server") which implements a multi-client server capability. --local host Local host name or IP address. If specified, OpenVPN will bind to this address only. If unspecified, OpenVPN will bind to all interfaces. --remote host [port] Remote host name or IP address. On the client, multiple --remote options may be specified for redundancy, each referring to a different OpenVPN server. The OpenVPN client will try to connect to a server at host:port in the order specified by the list of --remote options. The client will move on to the next host in the list, in the event of connection failure. Note that at any given time, the OpenVPN client will at most be connected to one server. Note that since UDP is connectionless, connection failure is defined by the --ping and --ping-restart options. Note the following corner case: If you use multiple --remote options, AND you are dropping root privileges on the client with --user and/or --group, AND the client is running a non-Windows OS, if the client needs to switch to a different server, and that server pushes back different TUN/TAP or route settings, the client may lack the necessary privileges to close and reopen the TUN/TAP interface. This could cause the client to exit with a fatal error. If --remote is unspecified, OpenVPN will listen for packets from any IP address, but will not act on those packets unless they pass all authentication tests. This requirement for authentication is binding on all potential peers, even those from known and supposedly trusted IP addresses (it is very easy to forge a source IP address on a UDP packet). When used in TCP mode, --remote will act as a filter, rejecting connections from any host which does not match host. If host is a DNS name which resolves to multiple IP addresses, one will be randomly chosen, providing a sort of basic load-balancing and failover capability. --remote-random When multiple --remote address/ports are specified, initially randomize the order of the list as a kind of basic load-balancing measure. --proto p Use protocol p for communicating with remote host. p can be udp, tcp-client, or tcp-server. The default protocol is udp when --proto is not specified. For UDP operation, --proto udp should be specified on both peers. For TCP operation, one peer must use --proto tcp-server and the other must use --proto tcp-client. A peer started with tcp-server will wait indefinitely for an incoming connection. A peer started with tcp-client will attempt to connect, and if that fails, will sleep for 5 seconds (adjustable via the --connect-retry option) and try again. Both TCP client and server will simulate a SIGUSR1 restart signal if either side resets the connection. OpenVPN is designed to operate optimally over UDP, but TCP capability is provided for situations where UDP cannot be used. In comparison with UDP, TCP will usually be somewhat less efficient and less robust when used over unreliable or congested networks. This article outlines some of problems with tunneling IP over TCP: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html There are certain cases, however, where using TCP may be advantageous from a security and robustness perspective, such as tunneling non-IP or application-level UDP protocols, or tunneling protocols which don't possess a built-in reliability layer. --connect-retry n For --proto tcp-client, take n as the number of seconds to wait between connection retries (default=5). --http-proxy server port [authfile] [auth-method] Connect to remote host through an HTTP proxy at address server and port port. If HTTP Proxy-Authenticate is required, authfile is a file containing a username and password on 2 lines, or "stdin" to prompt from console. auth-method should be one of "none", "basic", or "ntlm". --http-proxy-retry Retry indefinitely on HTTP proxy errors. If an HTTP proxy error occurs, simulate a SIGUSR1 reset. --http-proxy-timeout n Set proxy timeout to n seconds, default=5. --http-proxy-option type [parm] Set extended HTTP proxy options. Repeat to set multiple options. VERSION version -- Set HTTP version number to version (default=1.0). AGENT user-agent -- Set HTTP "User-Agent" string to user-agent. --socks-proxy server [port] Connect to remote host through a Socks5 proxy at address server and port port (default=1080). --socks-proxy-retry Retry indefinitely on Socks proxy errors. If a Socks proxy error occurs, simulate a SIGUSR1 reset. --resolv-retry n If hostname resolve fails for --remote, retry resolve for n seconds before failing. Set n to "infinite" to retry indefinitely. By default, --resolv-retry infinite is enabled. You can disable by setting n=0. --float Allow remote peer to change its IP address and/or port number, such as due to DHCP (this is the default if --remote is not used). --float when specified with --remote allows an OpenVPN session to initially connect to a peer at a known address, however if packets arrive from a new address and pass all authentication tests, the new address will take control of the session. This is useful when you are connecting to a peer which holds a dynamic address such as a dial-in user or DHCP client. Essentially, --float tells OpenVPN to accept authenticated packets from any address, not only the address which was specified in the --remote option. --ipchange cmd Execute shell command cmd when our remote ip-address is initially authenticated or changes. Execute as: cmd ip_address port_number Don't use --ipchange in --mode server mode. Use a --client-connect script instead. See the "Environmental Variables" section below for additional parameters passed as environmental variables. Note that cmd can be a shell command with multiple arguments, in which case all OpenVPN-generated arguments will be appended to cmd to build a command line which will be passed to the script. If you are running in a dynamic IP address environment where the IP addresses of either peer could change without notice, you can use this script, for example, to edit the /etc/hosts file with the current address of the peer. The script will be run every time the remote peer changes its IP address. Similarly if our IP address changes due to DHCP, we should configure our IP address change script (see man page for dhcpcd(8) ) to deliver a SIGHUP or SIGUSR1 signal to OpenVPN. OpenVPN will then reestablish a connection with its most recently authenticated peer on its new IP address. --port port TCP/UDP port number for both local and remote. The current default of 1194 represents the official IANA port number assignment for OpenVPN and has been used since version 2.0-beta17. Previous versions used port 5000 as the default. --lport port TCP/UDP port number for local. --rport port TCP/UDP port number for remote. --nobind Do not bind to local address and port. The IP stack will allocate a dynamic port for returning packets. Since the value of the dynamic port could not be known in advance by a peer, this option is only suitable for peers which will be initiating connections by using the --remote option. --dev tunX | tapX | null TUN/TAP virtual network device ( X can be omitted for a dynamic device.) See examples section below for an example on setting up a TUN device. You must use either tun devices on both ends of the connection or tap devices on both ends. You cannot mix them, as they represent different underlying protocols. tun devices encapsulate IPv4 while tap devices encapsulate ethernet 802.3. --dev-type device-type Which device type are we using? device-type should be tun or tap. Use this option only if the TUN/TAP device used with --dev does not begin with tun or tap. --tun-ipv6 Build a tun link capable of forwarding IPv6 traffic. Should be used in conjunction with --dev tun or --dev tunX. A warning will be displayed if no specific IPv6 TUN support for your OS has been compiled into OpenVPN. --dev-node node Explicitly set the device node rather than using /dev/net/tun, /dev/tun, /dev/tap, etc. If OpenVPN cannot figure out whether node is a TUN or TAP device based on the name, you should also specify --dev-type tun or --dev-type tap. On Windows systems, select the TAP-Win32 adapter which is named node in the Network Connections Control Panel or the raw GUID of the adapter enclosed by braces. The --show-adapters option under Windows can also be used to enumerate all available TAP-Win32 adapters and will show both the network connections control panel name and the GUID for each TAP-Win32 adapter. --ifconfig l rn Set TUN/TAP adapter parameters. l is the IP address of the local VPN endpoint. For TUN devices, rn is the IP address of the remote VPN endpoint. For TAP devices, rn is the subnet mask of the virtual ethernet segment which is being created or connected to. For TUN devices, which facilitate virtual point-to-point IP connections, the proper usage of --ifconfig is to use two private IP addresses which are not a member of any existing subnet which is in use. The IP addresses may be consecutive and should have their order reversed on the remote peer. After the VPN is established, by pinging rn, you will be pinging across the VPN. For TAP devices, which provide the ability to create virtual ethernet segments, --ifconfig is used to set an IP address and subnet mask just as a physical ethernet adapter would be similarly configured. If you are attempting to connect to a remote ethernet bridge, the IP address and subnet should be set to values which would be valid on the the bridged ethernet segment (note also that DHCP can be used for the same purpose). This option, while primarily a proxy for the ifconfig(8) command, is designed to simplify TUN/TAP tunnel configuration by providing a standard interface to the different ifconfig implementations on different platforms. --ifconfig parameters which are IP addresses can also be specified as a DNS or /etc/hosts file resolvable name. For TAP devices, --ifconfig should not be used if the TAP interface will be getting an IP address lease from a DHCP server. --ifconfig-noexec Don't actually execute ifconfig/netsh commands, instead pass --ifconfig parameters to scripts using environmental variables. --ifconfig-nowarn Don't output an options consistency check warning if the --ifconfig option on this side of the connection doesn't match the remote side. This is useful when you want to retain the overall benefits of the options consistency check (also see --disable-occ option) while only disabling the ifconfig component of the check. For example, if you have a configuration where the local host uses --ifconfig but the remote host does not, use --ifconfig-nowarn on the local host. This option will also silence warnings about potential address conflicts which occasionally annoy more experienced users by triggering "false positive" warnings. --route network/IP [netmask] [gateway] [metric] Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close. This option is intended as a convenience proxy for the route(8) shell command, while at the same time providing portable semantics across OpenVPN's platform space. netmask default -- 255.255.255.255 gateway default -- taken from --route-gateway or the second parameter to --ifconfig when --dev tun is specified. The default can be specified by leaving an option blank or setting it to "default". The network and gateway parameters can also be specified as a DNS or /etc/hosts file resolvable name, or as one of three special keywords: vpn_gateway -- The remote VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified). net_gateway -- The pre-existing IP default gateway, read from the routing table (not supported on all OSes). remote_host -- The --remote address if OpenVPN is being run in client mode, and is undefined in server mode. --route-gateway gw Specify a default gateway gw for use with --route. --route-delay [n] [w] Delay n seconds (default=0) after connection establishment, before adding routes. If n is 0, routes will be added immediately upon connection establishment. If --route-delay is omitted, routes will be added immediately after TUN/TAP device open and --up script execution, before any --user or --group privilege downgrade (or --chroot execution.) This option is designed to be useful in scenarios where DHCP is used to set tap adapter addresses. The delay will give the DHCP handshake time to complete before routes are added. On Windows, --route-delay tries to be more intelligent by waiting w seconds (w=30 by default) for the TAP-Win32 adapter to come up before adding routes. --route-up cmd Execute shell command cmd after routes are added, subject to --route-delay. See the "Environmental Variables" section below for additional parameters passed as environmental variables. Note that cmd can be a shell command with multiple arguments. --route-noexec Don't add or remove routes automatically. Instead pass routes to --route-up script using environmental variables. --redirect-gateway [local] [def1] (Experimental) Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN. This option performs three steps: (1) Create a static route for the --remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop. (2) Delete the default gateway route. (3) Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified). When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored. Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omitted. Add the def1 flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway. Using the def1 flag is highly recommended, and is currently planned to become the default by OpenVPN 2.1. --link-mtu n Sets an upper bound on the size of UDP packets which are sent between OpenVPN peers. It's best not to set this parameter unless you know what you're doing. --tun-mtu n Take the TUN device MTU to be n and derive the link MTU from it (default=1500). In most cases, you will probably want to leave this parameter set to its default value. The MTU (Maximum Transmission Units) is the maximum datagram size in bytes that can be sent unfragmented over a particular network path. OpenVPN requires that packets on the control or data channels be sent unfragmented. MTU problems often manifest themselves as connections which hang during periods of active usage. It's best to use the --fragment and/or --mssfix options to deal with MTU sizing issues. --tun-mtu-extra n Assume that the TUN/TAP device might return as many as n bytes more than the --tun-mtu size on read. This parameter defaults to 0, which is sufficient for most TUN devices. TAP devices may introduce additional overhead in excess of the MTU size, and a setting of 32 is the default when TAP devices are used. This parameter only controls internal OpenVPN buffer sizing, so there is no transmission overhead associated with using a larger value. --mtu-disc type Should we do Path MTU discovery on TCP/UDP channel? Only supported on OSes such as Linux that supports the necessary system call to set. 'no' -- Never send DF (Don't Fragment) frames 'maybe' -- Use per-route hints 'yes' -- Always DF (Don't Fragment) --mtu-test To empirically measure MTU on connection startup, add the --mtu-test option to your configuration. OpenVPN will send ping packets of various sizes to the remote peer and measure the largest packets which were successfully received. The --mtu-test process normally takes about 3 minutes to complete. --fragment max Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes. The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ). --fragment adds 4 bytes of overhead per datagram. See the --mssfix option below for an important related option to --fragment. It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead. Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation. --mssfix max Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp. --mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them. Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers. The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage. If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option. Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options: --tun-mtu 1500 --fragment 1300 --mssfix --sndbuf size Set the TCP/UDP socket send buffer size. Currently defaults to 65536 bytes. --rcvbuf size Set the TCP/UDP socket receive buffer size. Currently defaults to 65536 bytes. --txqueuelen n (Linux only) Set the TX queue length on the TUN/TAP interface. Currently defaults to 100. --shaper n Limit bandwidth of outgoing tunnel data to n bytes per second on the TCP/UDP port. If you want to limit the bandwidth in both directions, use this option on both peers. OpenVPN uses the following algorithm to implement traffic shaping: Given a shaper rate of n bytes per second, after a datagram write of b bytes is queued on the TCP/UDP port, wait a minimum of (b / n) seconds before queuing the next write. It should be noted that OpenVPN supports multiple tunnels between the same two peers, allowing you to construct full-speed and reduced bandwidth tunnels at the same time, routing low-priority data such as off-site backups over the reduced bandwidth tunnel, and other data over the full-speed tunnel. Also note that for low bandwidth tunnels (under 1000 bytes per second), you should probably use lower MTU values as well (see above), otherwise the packet latency will grow so large as to trigger timeouts in the TLS layer and TCP connections running over the tunnel. OpenVPN allows n to be between 100 bytes/sec and 100 Mbytes/sec. --inactive n (Experimental) Causes OpenVPN to exit after n seconds of inactivity on the TUN/TAP device. The time length of inactivity is measured since the last incoming tunnel packet. --ping n Ping remote over the TCP/UDP control channel if no packets have been sent for at least n seconds (specify --ping on both peers to cause ping packets to be sent in both directions since OpenVPN ping packets are not echoed like IP ping packets). When used in one of OpenVPN's secure modes (where --secret, --tls-server, or --tls-client is specified), the ping packet will be cryptographically secure. This option has two intended uses: (1) Compatibility with stateful firewalls. The periodic ping will ensure that a stateful firewall rule which allows OpenVPN UDP packets to pass will not time out. (2) To provide a basis for the remote to test the existence of its peer using the --ping-exit option. --ping-exit n Causes OpenVPN to exit after n seconds pass without reception of a ping or other packet from remote. This option can be combined with --inactive, --ping, and --ping-exit to create a two-tiered inactivity disconnect. For example, openvpn [options...] --inactive 3600 --ping 10 --ping-exit 60 when used on both peers will cause OpenVPN to exit within 60 seconds if its peer disconnects, but will exit after one hour if no actual tunnel data is exchanged. --ping-restart n Similar to --ping-exit, but trigger a SIGUSR1 restart after n seconds pass without reception of a ping or other packet from remote. This option is useful in cases where the remote peer has a dynamic IP address and a low-TTL DNS name is used to track the IP address using a service such as http://dyndns.org/ + a dynamic DNS client such as ddclient. If the peer cannot be reached, a |