Redirecting traffic to and from specific IP

MarkusDavey

Hello,

I have a routing issue with my ISP, and my work around is to (currently) push redirect gateway def1.

This is not desirable as i wish to only have data going to and from a specific IP (173.208.82.122 in this case).

I have the server running on Win XP, and the client is on Win 7.

Cheers.

maikcat

hi there,

what exactly is your question?
can you post configs (server/client)

Michael.

janjust

if you only need to route stuff to 173.208.82.122 via the VPN then simply add

route 173.208.82.122 255.255.255.255

to the client config and do not use redirect-gateway; however, you will also need to make sure that your vpn server does some sort of masquerading/NAtting, or the gateway/router connected to the VPN server needs to do this.
If 'redirect-gateway' was working for you then this was already in place.

MarkusDavey

janjust wroteif you only need to route stuff to 173.208.82.122 via the VPN then simply add
route 173.208.82.122 255.255.255.255
to the client config and do not use redirect-gateway; however, you will also need to make sure that your vpn server does some sort of masquerading/NAtting, or the gateway/router connected to the VPN server needs to do this.
If 'redirect-gateway' was working for you then this was already in place.

Any way to choose specific ports for this also?

Also, I am having horrific packet drop.

client

client
dev tun
proto udp
remote demeter.dyndns-server.com 1194   

resolv-retry infinite
nobind
persist-key
persist-tun

ca ca.crt
cert proteus.crt
key proteus.key
ns-cert-type server

comp-lzo
verb 3
#explicit-exit-notify 2
ping 10
ping-restart 600

route-method exe
route-delay 2

cipher none

server

port 1194
proto udp
dev tun
server 192.168.0.0 255.255.255.0  #you may choose any subnet. 10.0.0.x
is used for this example.

ca ca.crt                    #certs are optional. you may choose to go
with keys or passwords instead.
cert server.crt
key server.key
dh dh1024.pem

#push "redirect-gateway def1"
push "route 173.208.82.122 255.255.255.255"
push "dhcp-option DNS 8.8.8.8"       #google dns is a temporary
measure until the Windows XP solution is known

#the following commands are optional
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3

cipher none

janjust

routing is on IP level only, i.e. you cannot route only port 80 or 443.

As for horrible packet drop: are you talking about packets inside or outside of the tunnel? how do you quantify 'packet drop' ? dropped ICMP packets?

MarkusDavey

I run ping plotter, and i assume outside of the tunnel would be from the server to the outside internet. And yes, that is where the packet drop is.

ping plotter cannot show inter tunnel drop as all it shows is my PC to the server, then there to the outside world. So i do not know how much it is losing in the route from my PC to the server.

janjust

what about running
ping <server-VPN-IP>
for some time (or 'ping -t' on windows) ? that should give you some nice statistics.

MarkusDavey

I guess what i should ask, as a more open question. Is what can I do to streamline this the most for online gaming use? As that is what it is currently being used for.

Packet drop is 3% btw.

janjust

so what is the packet loss when comparing
ping -t <server-LAN-IP>
(i.e outside or no tunnel) vs
ping -t <server-VPN-IP>

if the line to the server is bad there's little you can do about it...

MarkusDavey

The server is totally unpingable when not connected to the VPN. Yet i can still remote desktop to it and everything.

and as stated above, through the VPN, pinging the server is 3% loss.

janjust

hmmm I'm still curious how good the line without the VPN is ; 3% packet loss is not great, but also not terrible. as an experiment you could also switch to 'proto tcp' to see if it has an effect - I'm pretty sure it shouldn't, but let's rule it out.

MarkusDavey

TCP over TCP = massive ping increase. I'll test the drop rate now but

Result : 0% loss

MarkusDavey

[bump]

janjust

bump? I'm still not certain what you meant with

TCP over TCP = massive ping increase. I'll test the drop rate now but

Result : 0% loss

tcp over tcp means no packet loss? that is good ; the ping time can be perhaps controlled using 'tcp-nodelay' on the server side.

MarkusDavey

janjust wrotebump? I'm still not certain what you meant with
TCP over TCP = massive ping increase. I'll test the drop rate now but

Result : 0% loss
tcp over tcp means no packet loss? that is good ; the ping time can be perhaps controlled using 'tcp-nodelay' on the server side.

Cheers, I'll give that a try

And what i meant with "tcp over tcp" is that it is commonly shunned. So i felt like mentioning that that was the case in that test.