Hullo alug,
I've got a computer here at home running debian that gets packages from a remote repository running behind a firewall at work using an openvpn connection. Local address is 192.168.10.6, remote webserver is known as repo.tcl.office. Remote nameserver is 192.168.10.10. Openvpn uses a tunnel of 12.3.3.0.
I have a second computer on my internal network, address assigned as 192.168.1.whatever by the dhcp server (192.168.1.2) that i would very much like to be able to access this repository.
At the moment all the second computer (a balloon-type board) knows is that it is on the network 192.168.1.0 and that its nameserver is 192.168.1.2...not much use to me at all, especially as the nameserver is not on the openvpn and has no idea about tcl.office. I had a try at assigning a static address on the 12.3.3.0 network to no avail, it couldn't ping the computer here on its tun 12.3.3.6 address. Adding various addresses to /etc/resolv.conf on the balloon make no difference.
Is this an impossible mission, or are there any tricks and tools i can be using to make this happen? Running openvpn on the balloon is not an option, alas.
Hints gratefully received.
Thanks,
Jenny
Jenny Hopkins hopkins.jenny@gmail.com
openvpn connection [...] Openvpn uses a tunnel of 12.3.3.0 [...] second computer on my internal network, 192.168.1.whatever [...] try at assigning a static address on the 12.3.3.0 network to no avail, it couldn't ping the computer here on its tun 12.3.3.6 address. [...] Is this an impossible mission, or are there any tricks and tools i can be using to make this happen? [...]
I got a bit lost among the missing IP addresses and quite exactly where "here" and "internal" actually are, but I didn't see you setting ip_forward on the openvpn-connected machine, which seems like one thing which might prevent it working.
It should be a case of setting the routing parameters correctly on each machine. The "route" config options in openvpn may help with that... or they might not.
Sometimes I resort to setting up NAT and masquerading in this sort of situation, mainly because I've been doing that for years and it avoids anything I don't control getting upset at there suddenly being a network where there was only a single IP address.
Here's a script I used for masquerading recently, but the device and network details may not reflect what you actually need to do, and there may be a security flaw in this (I suspect the MASQUERADE line should probably have -s 192.168.0.0/24 -i eth2 on it):
echo 1 > /proc/sys/net/ipv4/ip_forward iptables-restore << EOF *nat :PREROUTING ACCEPT [573:36591] :POSTROUTING ACCEPT [59:5375] :OUTPUT ACCEPT [43:6574] -A POSTROUTING -o tun1 -j MASQUERADE COMMIT *filter :INPUT ACCEPT [118:33140] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [170:21363] -A FORWARD -i tun1 -o eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.0.0/24 -i eth2 -j ACCEPT -A FORWARD -j LOG -A FORWARD -j DROP COMMIT EOF
Hope that helps,
On 22 August 2012 10:24, MJ Ray mjr@phonecoop.coop wrote:
Jenny Hopkins hopkins.jenny@gmail.com
openvpn connection [...] Openvpn uses a tunnel of 12.3.3.0 [...] second computer on my internal network, 192.168.1.whatever [...] try at assigning a static address on the 12.3.3.0 network to no avail, it couldn't ping the computer here on its tun 12.3.3.6 address. [...] Is this an impossible mission, or are there any tricks and tools i can be using to make this happen? [...]
I got a bit lost among the missing IP addresses and quite exactly where "here" and "internal" actually are, but I didn't see you setting ip_forward on the openvpn-connected machine, which seems like one thing which might prevent it working.
It should be a case of setting the routing parameters correctly on each machine. The "route" config options in openvpn may help with that... or they might not.
Sometimes I resort to setting up NAT and masquerading in this sort of situation, mainly because I've been doing that for years and it avoids anything I don't control getting upset at there suddenly being a network where there was only a single IP address.
Here's a script I used for masquerading recently, but the device and network details may not reflect what you actually need to do, and there may be a security flaw in this (I suspect the MASQUERADE line should probably have -s 192.168.0.0/24 -i eth2 on it):
echo 1 > /proc/sys/net/ipv4/ip_forward iptables-restore << EOF *nat :PREROUTING ACCEPT [573:36591] :POSTROUTING ACCEPT [59:5375] :OUTPUT ACCEPT [43:6574] -A POSTROUTING -o tun1 -j MASQUERADE COMMIT *filter :INPUT ACCEPT [118:33140] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [170:21363] -A FORWARD -i tun1 -o eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.0.0/24 -i eth2 -j ACCEPT -A FORWARD -j LOG -A FORWARD -j DROP COMMIT EOF
Hope that helps,
Thanks! What is the relevance of the -are they ports?- numbers in square brackets, like :PREROUTING ACCEPT [573:36591]?
I've now told the dhcp server the IP address of repo and told it the openvpn endpoint machine (here,192.168.1.6) is the gateway for there using routing table, and I've done "echo 1 > /proc/sys/net/ipv4/ip_forward". Now the local (i.e. home network where I am trying to set this all up) network knows that for repo.tcl.office they go to 192.168.1.6. The request is getting stuck there so I'll have a go at the masquerading.
(I had a go at iptable rules last night and, along with trying tinyproxy, inadvertently managed to redirect any requests on port 80 back to my own apache server :-))
Jenny
On 22 August 2012 11:17, Jenny Hopkins hopkins.jenny@gmail.com wrote:
On 22 August 2012 10:24, MJ Ray mjr@phonecoop.coop wrote:
Jenny Hopkins hopkins.jenny@gmail.com
openvpn connection [...] Openvpn uses a tunnel of 12.3.3.0 [...] second computer on my internal network, 192.168.1.whatever [...] try at assigning a static address on the 12.3.3.0 network to no avail, it couldn't ping the computer here on its tun 12.3.3.6 address. [...] Is this an impossible mission, or are there any tricks and tools i can be using to make this happen? [...]
I got a bit lost among the missing IP addresses and quite exactly where "here" and "internal" actually are, but I didn't see you setting ip_forward on the openvpn-connected machine, which seems like one thing which might prevent it working.
It should be a case of setting the routing parameters correctly on each machine. The "route" config options in openvpn may help with that... or they might not.
Sometimes I resort to setting up NAT and masquerading in this sort of situation, mainly because I've been doing that for years and it avoids anything I don't control getting upset at there suddenly being a network where there was only a single IP address.
Here's a script I used for masquerading recently, but the device and network details may not reflect what you actually need to do, and there may be a security flaw in this (I suspect the MASQUERADE line should probably have -s 192.168.0.0/24 -i eth2 on it):
echo 1 > /proc/sys/net/ipv4/ip_forward iptables-restore << EOF *nat :PREROUTING ACCEPT [573:36591] :POSTROUTING ACCEPT [59:5375] :OUTPUT ACCEPT [43:6574] -A POSTROUTING -o tun1 -j MASQUERADE COMMIT *filter :INPUT ACCEPT [118:33140] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [170:21363] -A FORWARD -i tun1 -o eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.0.0/24 -i eth2 -j ACCEPT -A FORWARD -j LOG -A FORWARD -j DROP COMMIT EOF
Hope that helps,
Thanks! What is the relevance of the -are they ports?- numbers in square brackets, like :PREROUTING ACCEPT [573:36591]?
I've now told the dhcp server the IP address of repo and told it the openvpn endpoint machine (here,192.168.1.6) is the gateway for there using routing table, and I've done "echo 1 > /proc/sys/net/ipv4/ip_forward". Now the local (i.e. home network where I am trying to set this all up) network knows that for repo.tcl.office they go to 192.168.1.6. The request is getting stuck there so I'll have a go at the masquerading.
(I had a go at iptable rules last night and, along with trying tinyproxy, inadvertently managed to redirect any requests on port 80 back to my own apache server :-))
Jenny
I should have also included that the openvpn is already adding this to my routing table on 192.168.1.6
Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.10.0 11.3.1.5 255.255.255.0 UG 0 0 0 tun0
Thanks,
Jen
On 22 August 2012 11:20, Jenny Hopkins hopkins.jenny@gmail.com wrote:
On 22 August 2012 11:17, Jenny Hopkins hopkins.jenny@gmail.com wrote:
On 22 August 2012 10:24, MJ Ray mjr@phonecoop.coop wrote:
Jenny Hopkins hopkins.jenny@gmail.com
openvpn connection [...] Openvpn uses a tunnel of 12.3.3.0 [...] second computer on my internal network, 192.168.1.whatever [...] try at assigning a static address on the 12.3.3.0 network to no avail, it couldn't ping the computer here on its tun 12.3.3.6 address. [...] Is this an impossible mission, or are there any tricks and tools i can be using to make this happen? [...]
I got a bit lost among the missing IP addresses and quite exactly where "here" and "internal" actually are, but I didn't see you setting ip_forward on the openvpn-connected machine, which seems like one thing which might prevent it working.
It should be a case of setting the routing parameters correctly on each machine. The "route" config options in openvpn may help with that... or they might not.
Sometimes I resort to setting up NAT and masquerading in this sort of situation, mainly because I've been doing that for years and it avoids anything I don't control getting upset at there suddenly being a network where there was only a single IP address.
Here's a script I used for masquerading recently, but the device and network details may not reflect what you actually need to do, and there may be a security flaw in this (I suspect the MASQUERADE line should probably have -s 192.168.0.0/24 -i eth2 on it):
echo 1 > /proc/sys/net/ipv4/ip_forward iptables-restore << EOF *nat :PREROUTING ACCEPT [573:36591] :POSTROUTING ACCEPT [59:5375] :OUTPUT ACCEPT [43:6574] -A POSTROUTING -o tun1 -j MASQUERADE COMMIT *filter :INPUT ACCEPT [118:33140] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [170:21363] -A FORWARD -i tun1 -o eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.0.0/24 -i eth2 -j ACCEPT -A FORWARD -j LOG -A FORWARD -j DROP COMMIT EOF
Hope that helps,
Thanks! What is the relevance of the -are they ports?- numbers in square brackets, like :PREROUTING ACCEPT [573:36591]?
I've now told the dhcp server the IP address of repo and told it the openvpn endpoint machine (here,192.168.1.6) is the gateway for there using routing table, and I've done "echo 1 > /proc/sys/net/ipv4/ip_forward". Now the local (i.e. home network where I am trying to set this all up) network knows that for repo.tcl.office they go to 192.168.1.6. The request is getting stuck there so I'll have a go at the masquerading.
(I had a go at iptable rules last night and, along with trying tinyproxy, inadvertently managed to redirect any requests on port 80 back to my own apache server :-))
Jenny
I should have also included that the openvpn is already adding this to my routing table on 192.168.1.6
Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.10.0 11.3.1.5 255.255.255.0 UG 0 0 0 tun0
...errrr, I mean Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.10.0 12.3.3.5 255.255.255.0 UG 0 0 0 tun0
Sorry! I'm sure you're all suitably confused now...i know I've managed to confuse myself.
Jen
Jenny asked:
Thanks! What is the relevance of the -are they ports?- numbers in square brackets, like :PREROUTING ACCEPT [573:36591]?
Damn I was hoping that you wouldn't ask that! ;-)
I think they might be counters (so not essential), but the man pages for iptables-save and iptables-restore aren't exactly clear and I've never dug further. Try deleting them and see if it still works? I can't because I'm not masquerading at the moment. I'm doing something far worse which I'm not going to document until it doesn't matter as much to me if the ISPs block it!
On that note, I should write up my tribulations with openvpn on Android some time. Any ALUGger got it working nicely?
Hope that helps,
On Wed, 22 Aug 2012 11:52:08 +0100 MJ Ray mjr@phonecoop.coop allegedly wrote:
Jenny asked:
Thanks! What is the relevance of the -are they ports?- numbers in square brackets, like :PREROUTING ACCEPT [573:36591]?
Damn I was hoping that you wouldn't ask that! ;-)
I think they might be counters (so not essential), but the man pages for iptables-save and iptables-restore aren't exactly clear and I've never dug further. Try deleting them and see if it still works? I can't because I'm not masquerading at the moment. I'm doing something far worse which I'm not going to document until it doesn't matter as much to me if the ISPs block it!
They are counters (bytes and packets). Try repeatedly running iptables-save and watch them go up. You can set them to zero "[0:0]" on each of the hook points before running iptables-restore.
On that note, I should write up my tribulations with openvpn on Android some time. Any ALUGger got it working nicely?
Nope. Not tried. But a guy called Mike Cardwell https://grepular.com/Punching_through_The_Great_Firewall_of_TMobile) seems to use it successfully. Last time I looked, openvpn seemed to require a rooted device. However, I've just run a search and it would seem that is no longer the case so I might take another look.
Mick --------------------------------------------------------------------- blog: baldric.net fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
Note that I have recently upgraded my GPG key see: http://baldric.net/2012/07/20/gpg-key-upgrade/ ---------------------------------------------------------------------
On Wed, 22 Aug 2012 11:52:08 +0100 MJ Ray mjr@phonecoop.coop allegedly wrote:
On that note, I should write up my tribulations with openvpn on Android some time. Any ALUGger got it working nicely?
Follow up to my reply of 22/8/12. I have sucessfully managed to get openvpn on android working.
I used Arne Schwabe's OpenVPN for Android at https://play.google.com/store/apps/details?id=de.blinkt.openvpn&hl=en
That app does not need a rooted device.
To get it set up, I imported a known good client configuration, plus certificates and key from a configuration I use on my netbook. The app provides quite a good import facility and builds its own configuration from the details you provide. It even stores the certs and key inline in its configuration so that you don't have to leave them lying around on sdcard where every manjack and his app can get at them. (However, I still don't like the idea of storing my cert and key on such an untrusted device so I have now deleted both the import and the built configuration. I just wanted to test to see if I could get it working).
The only difficulty I had was an initial failure caused by options in my client configuration which were not understood by the app. Once I had deleted these, and restarted I successfully built a tunnel to my server. The options I had to delete were:
resolv-retry infinite user nobody group nogroup mute-replay-warnings ns-cert-type server mute 20
Fortunately, the app gives you the option of editing the config file it generates from the imported client file. It even helpfully points out the options it doesn't understand.
All in all a good app (which even goes to the trouble to explain that it has the ability to intercept all your traffic). I just don't trust my android phone (a Samsung Galaxy SII) enough to leave such sensitive details on it.
Mick
--------------------------------------------------------------------- blog: baldric.net fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
Note that I have recently upgraded my GPG key see: http://baldric.net/2012/07/20/gpg-key-upgrade/ ---------------------------------------------------------------------
-
Jenny Hopkins -
mick -
MJ Ray