On 8/8/2012 10:51 PM, Sampsa Laine wrote:
Couldn't sleep so took at shot at compiling the bridge on the Solaris box :)
Looks like you're missing libpcap and bpf (?):
That's entirely possible. Or they could just be somewhere weird.
Sampsa
PS: How is this network connected to the rest of HECnet?
Currently it isn't. It was supposed to have simh running a copy of vms but that never got setup due to not being able to get the networking to function properly (tun/tap wasn't doing what it should).
I need to upgrade that machine so that I can use the crossbow network virtualization but upgrading a machine that i have limited access to is less than a fun idea. :)
Once we get the bridge working on wiggum I can also connect it to someone else. Last night while I was falling asleep I thought about this. I could also connect the bridge to my house, but that would be silly. If I'm going to do that I could just go ahead and setup the vpn tunnel to go to my house and skip wiggum altogether. :)
I'm setting up a new VM at home who's sole purpose in life is to be a vpn concentrator and HECnet bridge. I'll get you new vpn info sometime later this morning.
At that point you'll be bridged to my local DECnet network. I don't have any machines running locally (I really need to do something about that) but I'm connected to Dave M. and Peter L. via GRE tunnels on our cisco boxes.
-brian
On 8 Aug 2012, at 23:56, Johnny Billquist wrote:
On 2012-08-08 15:42, Bob Armstrong wrote:
I notice that the bridge is down again this morning. Is it just me?
Nope. I noticed that Psilo was down, but only now did I recheck and as psilo was back up, I restarted the bridge.
I've restarted mine several times and I'm still not getting anything outside my LAN. :\
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
I'd say the vpn works fine. :)
wonko at wiggum$ ssh brian at 10.42.3.2
The authenticity of host '10.42.3.2 (10.42.3.2)' can't be established.
RSA key fingerprint is 1b:75:4e:d2:b5:d2:6b:85:0d:d3:92:f7:13:a1:34:78.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.42.3.2' (RSA) to the list of known hosts.
Password:
LabHost:~ brian$
LabHost:~ brian$ ssh wonko at 10.42.3.1
The authenticity of host '10.42.3.1 (10.42.3.1)' can't be established.
RSA key fingerprint is 2d:e5:92:24:a3:1e:c4:16:21:d9:d0:63:bc:7a:4f:d8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.42.3.1' (RSA) to the list of known hosts.
Password:
Last login: Wed Aug 8 20:25:36 2012 from 216-15-64-181.c
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
wonko at wiggum$
On 8/8/2012 8:24 PM, Sampsa Laine wrote:
OK,
It's brian/ChangeMe2012
Sampsa
On 9 Aug 2012, at 03:14, Brian Hechinger wrote:
I'm pretty sure it's working. Can you give me an account on whatever is running it on your end so I can try to test it?
-brian
On Aug 8, 2012, at 18:36, Sampsa Laine <sampsa at mac.com> wrote:
Dude, I'm still not able to ping anything on your side.
You sure the VPN is working?
Sampsa
PS: Syrian state TV is freaking me out, only martial music and they keep saying the word "terrorist" every 2 seconds on the news.
On 9 Aug 2012, at 01:29, Brian Hechinger wrote:
We're good to go. I just need a copy of the bridge program when you get the chance.
-brian
On Aug 8, 2012, at 15:36, Sampsa Laine <sampsa at mac.com> wrote:
No worries, this is my secondary HECNET connection.
The rest of area 8 sits on a bridge and multiple UDP MULTINET tunnels as it should :)
sampsa
On 8 Aug 2012, at 22:28, Brian Hechinger wrote:
I can ssh to 10.42.3.2 and get a key warning (which makes sense as your machine has a different key than the one i used to go to on that IP, so that's a good thing)
-brian
On 8/8/2012 12:54 PM, Sampsa Laine wrote:
OK, got Tunnelblick to connect to your end (it's a frontend for OS X openvpn).
But even though ifconfig looks right:
$ ifconfig tun0
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.42.3.2 --> 10.42.3.99 netmask 0xffffffff
open (pid 701)
Ping won't work:
$ ping 10.42.3.99
PING 10.42.3.99 (10.42.3.99): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
On 8 Aug 2012, at 19:46, Brian Hechinger wrote:
Also, I created you an account on wiggum. I named it kermit unless you'd prefer something else. Password is ChangeMe2012
that's wiggum.4amlunch.net, btw.
-brian
On 8/8/2012 12:42 PM, Sampsa Laine wrote:
I do, somewhere.
Let's get the VPN going first.
On 8 Aug 2012, at 19:40, Brian Hechinger wrote:
Got a copy of the bridge? Update seems to be unavailable.
-brian
On 8/8/2012 12:27 PM, Sampsa Laine wrote:
Thanks dude. Send me the connection details.
Sampsa
On 8 Aug 2012, at 19:27, Brian Hechinger wrote:
Yeah, everything IP goes over VPN.
Ok, you win. I'll setup the bridge. :)
-brian
On 8/8/2012 12:26 PM, Sampsa Laine wrote:
Well I was thinking something simpler:
You set up a VPN server on your end to listen to connections.
I connect to your VPN server.
Let's say I get IP 10.0.01, your bridge is on 10.0.0.2.
I then just point my bridge at 10.0.0.2:4711, you point yours at the 10.0.0.1:4711.
UDP goes over VPN?
Sampsa
On 8 Aug 2012, at 19:16, Brian Hechinger wrote:
Yeah, that's an option, but here is what I was thinking.
You connect via openvpn to me. I redirect a port on my IP to go to yours.
For example, my server is 208.85.173.157. My end of the vpn tunnel is 10.42.3.1 and your end of the vpn tunnel is 10.42.3.2.
I had a nat rule that takes tcp port 9022 from 208.85.173.157 and redirects it to 10.42.3.2 port 22.
What this would allow you to do is ssh to 208.85.173.157:9022 and get directly connected to whatever is running openvpn on your end.
In theory.
In reality, it's not working for some reason. :(
It really should, but I haven't touched ipf/ipnat on this box in so long I might have something setup incorrectly (i used to do exactly this).
-brian
On 8/8/2012 12:12 PM, Sampsa Laine wrote:
Dude, there is no server. Let me explain :)
My ISP offers non-public IPs, so that's NAT one one - no way to forward a port.
Then I got a router, doing the local NATing, NAT two. Sure i could forward a port, but it ain't gonna help as the packets will never get to me from the ISP.
So I figure I connect out to you via OpenVPN, get a static IP x.x.x.x and then point my bridge at your static IP y.y.y.y (both of these are on the VPN), and you do vice versa.
Sound reasonable?
On 8 Aug 2012, at 19:09, Brian Hechinger wrote:
It might come to that but what I'm attempting to do now is make you a bit more autonomous. If all goes according to plan (and so far it isn't) i'll be redirecting ports on my IP directly to your server.
If this doesn't work I'll just setup the bridge for you to relay through.
-brian
On 8/8/2012 11:56 AM, Sampsa Laine wrote:
And then my assumption is that I get a static IP (non-routable, of course) for my side and we point our bridges at each other over UDP?
Sampsa
On 8 Aug 2012, at 18:31, Brian Hechinger wrote:
It doesn't really matter I don't think. The OpenVPN config file is the same no matter where you use it.
-brian
On 8/8/2012 10:50 AM, Sampsa Laine wrote:
I can run it from both an OS X box or Linux?
Which is easier to configure?
Sampsa
On 8 Aug 2012, at 16:55, Brian Hechinger wrote:
I should have some time today. Let me take a quick look at it and see. I can simulate your setup so I can test it here before passing it off to you
-brian
On 8/8/2012 9:19 AM, Sampsa Laine wrote:
Brian,
When would be a good time to set up this OpenVPN thing for you?
Let me know.
Sampsa
On 6 Aug 2012, at 23:43, Sampsa Laine wrote:
I'm game - never set it up on a Linux box before, though
On 6 Aug 2012, at 23:13, Brian Hechinger wrote:
A possible option would be to setup an OpenVPN tunnel somewhere to go through. Maybe not pretty, but it'll work.
If you want to try that email me off list and we can set it up on my colo box.
-brian
On Aug 6, 2012, at 16:00, Sampsa Laine <sampsa at mac.com> wrote:
On 6 Aug 2012, at 20:07, Johnny Billquist wrote:
Ah well, I could go on... Suffice to say that it's not because I'm opposed to the features that a TCP connection, or DNS resolution would give, but I prioritize something that I feel confident is working to features. And doing a proper solution with all these aspects is more work than I have cared to put into it. The bridge program is a hack.
As Paul mention, pthreads would probably be a good start if you want to do something more intelligent. You need to start thinking asynchronously.
My desire for this is basically because my ISP is NAT'd to hell - I have no way of getting UDP packets back to my network, as the ISP gives me a non-routable address.
Why go with this ISP? Well it's about 3x faster than the DSL I can get in the sticks over a 3G signal, with unlimited bandwidth and usage.
But sucks for HECnet..
Sampsa
I'll get it built tomorrow. Thanks!!
-brian
On Aug 8, 2012, at 18:32, Sampsa Laine <sampsa at mac.com> wrote:
Cool. Sending you the .c file and a sample config, ok?
<bridge.c>
<bridge.conf>
On 9 Aug 2012, at 01:29, Brian Hechinger wrote:
We're good to go. I just need a copy of the bridge program when you get the chance.
-brian
On Aug 8, 2012, at 15:36, Sampsa Laine <sampsa at mac.com> wrote:
No worries, this is my secondary HECNET connection.
The rest of area 8 sits on a bridge and multiple UDP MULTINET tunnels as it should :)
sampsa
On 8 Aug 2012, at 22:28, Brian Hechinger wrote:
I can ssh to 10.42.3.2 and get a key warning (which makes sense as your machine has a different key than the one i used to go to on that IP, so that's a good thing)
-brian
On 8/8/2012 12:54 PM, Sampsa Laine wrote:
OK, got Tunnelblick to connect to your end (it's a frontend for OS X openvpn).
But even though ifconfig looks right:
$ ifconfig tun0
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.42.3.2 --> 10.42.3.99 netmask 0xffffffff
open (pid 701)
Ping won't work:
$ ping 10.42.3.99
PING 10.42.3.99 (10.42.3.99): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
On 8 Aug 2012, at 19:46, Brian Hechinger wrote:
Also, I created you an account on wiggum. I named it kermit unless you'd prefer something else. Password is ChangeMe2012
that's wiggum.4amlunch.net, btw.
-brian
On 8/8/2012 12:42 PM, Sampsa Laine wrote:
I do, somewhere.
Let's get the VPN going first.
On 8 Aug 2012, at 19:40, Brian Hechinger wrote:
Got a copy of the bridge? Update seems to be unavailable.
-brian
On 8/8/2012 12:27 PM, Sampsa Laine wrote:
Thanks dude. Send me the connection details.
Sampsa
On 8 Aug 2012, at 19:27, Brian Hechinger wrote:
Yeah, everything IP goes over VPN.
Ok, you win. I'll setup the bridge. :)
-brian
On 8/8/2012 12:26 PM, Sampsa Laine wrote:
Well I was thinking something simpler:
You set up a VPN server on your end to listen to connections.
I connect to your VPN server.
Let's say I get IP 10.0.01, your bridge is on 10.0.0.2.
I then just point my bridge at 10.0.0.2:4711, you point yours at the 10.0.0.1:4711.
UDP goes over VPN?
Sampsa
On 8 Aug 2012, at 19:16, Brian Hechinger wrote:
Yeah, that's an option, but here is what I was thinking.
You connect via openvpn to me. I redirect a port on my IP to go to yours.
For example, my server is 208.85.173.157. My end of the vpn tunnel is 10.42.3.1 and your end of the vpn tunnel is 10.42.3.2.
I had a nat rule that takes tcp port 9022 from 208.85.173.157 and redirects it to 10.42.3.2 port 22.
What this would allow you to do is ssh to 208.85.173.157:9022 and get directly connected to whatever is running openvpn on your end.
In theory.
In reality, it's not working for some reason. :(
It really should, but I haven't touched ipf/ipnat on this box in so long I might have something setup incorrectly (i used to do exactly this).
-brian
On 8/8/2012 12:12 PM, Sampsa Laine wrote:
Dude, there is no server. Let me explain :)
My ISP offers non-public IPs, so that's NAT one one - no way to forward a port.
Then I got a router, doing the local NATing, NAT two. Sure i could forward a port, but it ain't gonna help as the packets will never get to me from the ISP.
So I figure I connect out to you via OpenVPN, get a static IP x.x.x.x and then point my bridge at your static IP y.y.y.y (both of these are on the VPN), and you do vice versa.
Sound reasonable?
On 8 Aug 2012, at 19:09, Brian Hechinger wrote:
It might come to that but what I'm attempting to do now is make you a bit more autonomous. If all goes according to plan (and so far it isn't) i'll be redirecting ports on my IP directly to your server.
If this doesn't work I'll just setup the bridge for you to relay through.
-brian
On 8/8/2012 11:56 AM, Sampsa Laine wrote:
And then my assumption is that I get a static IP (non-routable, of course) for my side and we point our bridges at each other over UDP?
Sampsa
On 8 Aug 2012, at 18:31, Brian Hechinger wrote:
It doesn't really matter I don't think. The OpenVPN config file is the same no matter where you use it.
-brian
On 8/8/2012 10:50 AM, Sampsa Laine wrote:
I can run it from both an OS X box or Linux?
Which is easier to configure?
Sampsa
On 8 Aug 2012, at 16:55, Brian Hechinger wrote:
I should have some time today. Let me take a quick look at it and see. I can simulate your setup so I can test it here before passing it off to you
-brian
On 8/8/2012 9:19 AM, Sampsa Laine wrote:
Brian,
When would be a good time to set up this OpenVPN thing for you?
Let me know.
Sampsa
On 6 Aug 2012, at 23:43, Sampsa Laine wrote:
I'm game - never set it up on a Linux box before, though
On 6 Aug 2012, at 23:13, Brian Hechinger wrote:
A possible option would be to setup an OpenVPN tunnel somewhere to go through. Maybe not pretty, but it'll work.
If you want to try that email me off list and we can set it up on my colo box.
-brian
On Aug 6, 2012, at 16:00, Sampsa Laine <sampsa at mac.com> wrote:
On 6 Aug 2012, at 20:07, Johnny Billquist wrote:
Ah well, I could go on... Suffice to say that it's not because I'm opposed to the features that a TCP connection, or DNS resolution would give, but I prioritize something that I feel confident is working to features. And doing a proper solution with all these aspects is more work than I have cared to put into it. The bridge program is a hack.
As Paul mention, pthreads would probably be a good start if you want to do something more intelligent. You need to start thinking asynchronously.
My desire for this is basically because my ISP is NAT'd to hell - I have no way of getting UDP packets back to my network, as the ISP gives me a non-routable address.
Why go with this ISP? Well it's about 3x faster than the DSL I can get in the sticks over a 3G signal, with unlimited bandwidth and usage.
But sucks for HECnet..
Sampsa
Also, what's going on in Syria? Craziness? I'm bad about following the news. :)
-brian
On Aug 8, 2012, at 18:36, Sampsa Laine <sampsa at mac.com> wrote:
Dude, I'm still not able to ping anything on your side.
You sure the VPN is working?
Sampsa
PS: Syrian state TV is freaking me out, only martial music and they keep saying the word "terrorist" every 2 seconds on the news.
On 9 Aug 2012, at 01:29, Brian Hechinger wrote:
We're good to go. I just need a copy of the bridge program when you get the chance.
-brian
On Aug 8, 2012, at 15:36, Sampsa Laine <sampsa at mac.com> wrote:
No worries, this is my secondary HECNET connection.
The rest of area 8 sits on a bridge and multiple UDP MULTINET tunnels as it should :)
sampsa
On 8 Aug 2012, at 22:28, Brian Hechinger wrote:
I can ssh to 10.42.3.2 and get a key warning (which makes sense as your machine has a different key than the one i used to go to on that IP, so that's a good thing)
-brian
On 8/8/2012 12:54 PM, Sampsa Laine wrote:
OK, got Tunnelblick to connect to your end (it's a frontend for OS X openvpn).
But even though ifconfig looks right:
$ ifconfig tun0
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.42.3.2 --> 10.42.3.99 netmask 0xffffffff
open (pid 701)
Ping won't work:
$ ping 10.42.3.99
PING 10.42.3.99 (10.42.3.99): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
On 8 Aug 2012, at 19:46, Brian Hechinger wrote:
Also, I created you an account on wiggum. I named it kermit unless you'd prefer something else. Password is ChangeMe2012
that's wiggum.4amlunch.net, btw.
-brian
On 8/8/2012 12:42 PM, Sampsa Laine wrote:
I do, somewhere.
Let's get the VPN going first.
On 8 Aug 2012, at 19:40, Brian Hechinger wrote:
Got a copy of the bridge? Update seems to be unavailable.
-brian
On 8/8/2012 12:27 PM, Sampsa Laine wrote:
Thanks dude. Send me the connection details.
Sampsa
On 8 Aug 2012, at 19:27, Brian Hechinger wrote:
Yeah, everything IP goes over VPN.
Ok, you win. I'll setup the bridge. :)
-brian
On 8/8/2012 12:26 PM, Sampsa Laine wrote:
Well I was thinking something simpler:
You set up a VPN server on your end to listen to connections.
I connect to your VPN server.
Let's say I get IP 10.0.01, your bridge is on 10.0.0.2.
I then just point my bridge at 10.0.0.2:4711, you point yours at the 10.0.0.1:4711.
UDP goes over VPN?
Sampsa
On 8 Aug 2012, at 19:16, Brian Hechinger wrote:
Yeah, that's an option, but here is what I was thinking.
You connect via openvpn to me. I redirect a port on my IP to go to yours.
For example, my server is 208.85.173.157. My end of the vpn tunnel is 10.42.3.1 and your end of the vpn tunnel is 10.42.3.2.
I had a nat rule that takes tcp port 9022 from 208.85.173.157 and redirects it to 10.42.3.2 port 22.
What this would allow you to do is ssh to 208.85.173.157:9022 and get directly connected to whatever is running openvpn on your end.
In theory.
In reality, it's not working for some reason. :(
It really should, but I haven't touched ipf/ipnat on this box in so long I might have something setup incorrectly (i used to do exactly this).
-brian
On 8/8/2012 12:12 PM, Sampsa Laine wrote:
Dude, there is no server. Let me explain :)
My ISP offers non-public IPs, so that's NAT one one - no way to forward a port.
Then I got a router, doing the local NATing, NAT two. Sure i could forward a port, but it ain't gonna help as the packets will never get to me from the ISP.
So I figure I connect out to you via OpenVPN, get a static IP x.x.x.x and then point my bridge at your static IP y.y.y.y (both of these are on the VPN), and you do vice versa.
Sound reasonable?
On 8 Aug 2012, at 19:09, Brian Hechinger wrote:
It might come to that but what I'm attempting to do now is make you a bit more autonomous. If all goes according to plan (and so far it isn't) i'll be redirecting ports on my IP directly to your server.
If this doesn't work I'll just setup the bridge for you to relay through.
-brian
On 8/8/2012 11:56 AM, Sampsa Laine wrote:
And then my assumption is that I get a static IP (non-routable, of course) for my side and we point our bridges at each other over UDP?
Sampsa
On 8 Aug 2012, at 18:31, Brian Hechinger wrote:
It doesn't really matter I don't think. The OpenVPN config file is the same no matter where you use it.
-brian
On 8/8/2012 10:50 AM, Sampsa Laine wrote:
I can run it from both an OS X box or Linux?
Which is easier to configure?
Sampsa
On 8 Aug 2012, at 16:55, Brian Hechinger wrote:
I should have some time today. Let me take a quick look at it and see. I can simulate your setup so I can test it here before passing it off to you
-brian
On 8/8/2012 9:19 AM, Sampsa Laine wrote:
Brian,
When would be a good time to set up this OpenVPN thing for you?
Let me know.
Sampsa
On 6 Aug 2012, at 23:43, Sampsa Laine wrote:
I'm game - never set it up on a Linux box before, though
On 6 Aug 2012, at 23:13, Brian Hechinger wrote:
A possible option would be to setup an OpenVPN tunnel somewhere to go through. Maybe not pretty, but it'll work.
If you want to try that email me off list and we can set it up on my colo box.
-brian
On Aug 6, 2012, at 16:00, Sampsa Laine <sampsa at mac.com> wrote:
On 6 Aug 2012, at 20:07, Johnny Billquist wrote:
Ah well, I could go on... Suffice to say that it's not because I'm opposed to the features that a TCP connection, or DNS resolution would give, but I prioritize something that I feel confident is working to features. And doing a proper solution with all these aspects is more work than I have cared to put into it. The bridge program is a hack.
As Paul mention, pthreads would probably be a good start if you want to do something more intelligent. You need to start thinking asynchronously.
My desire for this is basically because my ISP is NAT'd to hell - I have no way of getting UDP packets back to my network, as the ISP gives me a non-routable address.
Why go with this ISP? Well it's about 3x faster than the DSL I can get in the sticks over a 3G signal, with unlimited bandwidth and usage.
But sucks for HECnet..
Sampsa
I'm pretty sure it's working. Can you give me an account on whatever is running it on your end so I can try to test it?
-brian
On Aug 8, 2012, at 18:36, Sampsa Laine <sampsa at mac.com> wrote:
Dude, I'm still not able to ping anything on your side.
You sure the VPN is working?
Sampsa
PS: Syrian state TV is freaking me out, only martial music and they keep saying the word "terrorist" every 2 seconds on the news.
On 9 Aug 2012, at 01:29, Brian Hechinger wrote:
We're good to go. I just need a copy of the bridge program when you get the chance.
-brian
On Aug 8, 2012, at 15:36, Sampsa Laine <sampsa at mac.com> wrote:
No worries, this is my secondary HECNET connection.
The rest of area 8 sits on a bridge and multiple UDP MULTINET tunnels as it should :)
sampsa
On 8 Aug 2012, at 22:28, Brian Hechinger wrote:
I can ssh to 10.42.3.2 and get a key warning (which makes sense as your machine has a different key than the one i used to go to on that IP, so that's a good thing)
-brian
On 8/8/2012 12:54 PM, Sampsa Laine wrote:
OK, got Tunnelblick to connect to your end (it's a frontend for OS X openvpn).
But even though ifconfig looks right:
$ ifconfig tun0
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.42.3.2 --> 10.42.3.99 netmask 0xffffffff
open (pid 701)
Ping won't work:
$ ping 10.42.3.99
PING 10.42.3.99 (10.42.3.99): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
On 8 Aug 2012, at 19:46, Brian Hechinger wrote:
Also, I created you an account on wiggum. I named it kermit unless you'd prefer something else. Password is ChangeMe2012
that's wiggum.4amlunch.net, btw.
-brian
On 8/8/2012 12:42 PM, Sampsa Laine wrote:
I do, somewhere.
Let's get the VPN going first.
On 8 Aug 2012, at 19:40, Brian Hechinger wrote:
Got a copy of the bridge? Update seems to be unavailable.
-brian
On 8/8/2012 12:27 PM, Sampsa Laine wrote:
Thanks dude. Send me the connection details.
Sampsa
On 8 Aug 2012, at 19:27, Brian Hechinger wrote:
Yeah, everything IP goes over VPN.
Ok, you win. I'll setup the bridge. :)
-brian
On 8/8/2012 12:26 PM, Sampsa Laine wrote:
Well I was thinking something simpler:
You set up a VPN server on your end to listen to connections.
I connect to your VPN server.
Let's say I get IP 10.0.01, your bridge is on 10.0.0.2.
I then just point my bridge at 10.0.0.2:4711, you point yours at the 10.0.0.1:4711.
UDP goes over VPN?
Sampsa
On 8 Aug 2012, at 19:16, Brian Hechinger wrote:
Yeah, that's an option, but here is what I was thinking.
You connect via openvpn to me. I redirect a port on my IP to go to yours.
For example, my server is 208.85.173.157. My end of the vpn tunnel is 10.42.3.1 and your end of the vpn tunnel is 10.42.3.2.
I had a nat rule that takes tcp port 9022 from 208.85.173.157 and redirects it to 10.42.3.2 port 22.
What this would allow you to do is ssh to 208.85.173.157:9022 and get directly connected to whatever is running openvpn on your end.
In theory.
In reality, it's not working for some reason. :(
It really should, but I haven't touched ipf/ipnat on this box in so long I might have something setup incorrectly (i used to do exactly this).
-brian
On 8/8/2012 12:12 PM, Sampsa Laine wrote:
Dude, there is no server. Let me explain :)
My ISP offers non-public IPs, so that's NAT one one - no way to forward a port.
Then I got a router, doing the local NATing, NAT two. Sure i could forward a port, but it ain't gonna help as the packets will never get to me from the ISP.
So I figure I connect out to you via OpenVPN, get a static IP x.x.x.x and then point my bridge at your static IP y.y.y.y (both of these are on the VPN), and you do vice versa.
Sound reasonable?
On 8 Aug 2012, at 19:09, Brian Hechinger wrote:
It might come to that but what I'm attempting to do now is make you a bit more autonomous. If all goes according to plan (and so far it isn't) i'll be redirecting ports on my IP directly to your server.
If this doesn't work I'll just setup the bridge for you to relay through.
-brian
On 8/8/2012 11:56 AM, Sampsa Laine wrote:
And then my assumption is that I get a static IP (non-routable, of course) for my side and we point our bridges at each other over UDP?
Sampsa
On 8 Aug 2012, at 18:31, Brian Hechinger wrote:
It doesn't really matter I don't think. The OpenVPN config file is the same no matter where you use it.
-brian
On 8/8/2012 10:50 AM, Sampsa Laine wrote:
I can run it from both an OS X box or Linux?
Which is easier to configure?
Sampsa
On 8 Aug 2012, at 16:55, Brian Hechinger wrote:
I should have some time today. Let me take a quick look at it and see. I can simulate your setup so I can test it here before passing it off to you
-brian
On 8/8/2012 9:19 AM, Sampsa Laine wrote:
Brian,
When would be a good time to set up this OpenVPN thing for you?
Let me know.
Sampsa
On 6 Aug 2012, at 23:43, Sampsa Laine wrote:
I'm game - never set it up on a Linux box before, though
On 6 Aug 2012, at 23:13, Brian Hechinger wrote:
A possible option would be to setup an OpenVPN tunnel somewhere to go through. Maybe not pretty, but it'll work.
If you want to try that email me off list and we can set it up on my colo box.
-brian
On Aug 6, 2012, at 16:00, Sampsa Laine <sampsa at mac.com> wrote:
On 6 Aug 2012, at 20:07, Johnny Billquist wrote:
Ah well, I could go on... Suffice to say that it's not because I'm opposed to the features that a TCP connection, or DNS resolution would give, but I prioritize something that I feel confident is working to features. And doing a proper solution with all these aspects is more work than I have cared to put into it. The bridge program is a hack.
As Paul mention, pthreads would probably be a good start if you want to do something more intelligent. You need to start thinking asynchronously.
My desire for this is basically because my ISP is NAT'd to hell - I have no way of getting UDP packets back to my network, as the ISP gives me a non-routable address.
Why go with this ISP? Well it's about 3x faster than the DSL I can get in the sticks over a 3G signal, with unlimited bandwidth and usage.
But sucks for HECnet..
Sampsa
On 2012-08-08 15:42, Bob Armstrong wrote:
I notice that the bridge is down again this morning. Is it just me?
Nope. I noticed that Psilo was down, but only now did I recheck and as psilo was back up, I restarted the bridge.
Johnny
We're good to go. I just need a copy of the bridge program when you get the chance.
-brian
On Aug 8, 2012, at 15:36, Sampsa Laine <sampsa at mac.com> wrote:
No worries, this is my secondary HECNET connection.
The rest of area 8 sits on a bridge and multiple UDP MULTINET tunnels as it should :)
sampsa
On 8 Aug 2012, at 22:28, Brian Hechinger wrote:
I can ssh to 10.42.3.2 and get a key warning (which makes sense as your machine has a different key than the one i used to go to on that IP, so that's a good thing)
-brian
On 8/8/2012 12:54 PM, Sampsa Laine wrote:
OK, got Tunnelblick to connect to your end (it's a frontend for OS X openvpn).
But even though ifconfig looks right:
$ ifconfig tun0
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.42.3.2 --> 10.42.3.99 netmask 0xffffffff
open (pid 701)
Ping won't work:
$ ping 10.42.3.99
PING 10.42.3.99 (10.42.3.99): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
On 8 Aug 2012, at 19:46, Brian Hechinger wrote:
Also, I created you an account on wiggum. I named it kermit unless you'd prefer something else. Password is ChangeMe2012
that's wiggum.4amlunch.net, btw.
-brian
On 8/8/2012 12:42 PM, Sampsa Laine wrote:
I do, somewhere.
Let's get the VPN going first.
On 8 Aug 2012, at 19:40, Brian Hechinger wrote:
Got a copy of the bridge? Update seems to be unavailable.
-brian
On 8/8/2012 12:27 PM, Sampsa Laine wrote:
Thanks dude. Send me the connection details.
Sampsa
On 8 Aug 2012, at 19:27, Brian Hechinger wrote:
Yeah, everything IP goes over VPN.
Ok, you win. I'll setup the bridge. :)
-brian
On 8/8/2012 12:26 PM, Sampsa Laine wrote:
Well I was thinking something simpler:
You set up a VPN server on your end to listen to connections.
I connect to your VPN server.
Let's say I get IP 10.0.01, your bridge is on 10.0.0.2.
I then just point my bridge at 10.0.0.2:4711, you point yours at the 10.0.0.1:4711.
UDP goes over VPN?
Sampsa
On 8 Aug 2012, at 19:16, Brian Hechinger wrote:
Yeah, that's an option, but here is what I was thinking.
You connect via openvpn to me. I redirect a port on my IP to go to yours.
For example, my server is 208.85.173.157. My end of the vpn tunnel is 10.42.3.1 and your end of the vpn tunnel is 10.42.3.2.
I had a nat rule that takes tcp port 9022 from 208.85.173.157 and redirects it to 10.42.3.2 port 22.
What this would allow you to do is ssh to 208.85.173.157:9022 and get directly connected to whatever is running openvpn on your end.
In theory.
In reality, it's not working for some reason. :(
It really should, but I haven't touched ipf/ipnat on this box in so long I might have something setup incorrectly (i used to do exactly this).
-brian
On 8/8/2012 12:12 PM, Sampsa Laine wrote:
Dude, there is no server. Let me explain :)
My ISP offers non-public IPs, so that's NAT one one - no way to forward a port.
Then I got a router, doing the local NATing, NAT two. Sure i could forward a port, but it ain't gonna help as the packets will never get to me from the ISP.
So I figure I connect out to you via OpenVPN, get a static IP x.x.x.x and then point my bridge at your static IP y.y.y.y (both of these are on the VPN), and you do vice versa.
Sound reasonable?
On 8 Aug 2012, at 19:09, Brian Hechinger wrote:
It might come to that but what I'm attempting to do now is make you a bit more autonomous. If all goes according to plan (and so far it isn't) i'll be redirecting ports on my IP directly to your server.
If this doesn't work I'll just setup the bridge for you to relay through.
-brian
On 8/8/2012 11:56 AM, Sampsa Laine wrote:
And then my assumption is that I get a static IP (non-routable, of course) for my side and we point our bridges at each other over UDP?
Sampsa
On 8 Aug 2012, at 18:31, Brian Hechinger wrote:
It doesn't really matter I don't think. The OpenVPN config file is the same no matter where you use it.
-brian
On 8/8/2012 10:50 AM, Sampsa Laine wrote:
I can run it from both an OS X box or Linux?
Which is easier to configure?
Sampsa
On 8 Aug 2012, at 16:55, Brian Hechinger wrote:
I should have some time today. Let me take a quick look at it and see. I can simulate your setup so I can test it here before passing it off to you
-brian
On 8/8/2012 9:19 AM, Sampsa Laine wrote:
Brian,
When would be a good time to set up this OpenVPN thing for you?
Let me know.
Sampsa
On 6 Aug 2012, at 23:43, Sampsa Laine wrote:
I'm game - never set it up on a Linux box before, though
On 6 Aug 2012, at 23:13, Brian Hechinger wrote:
A possible option would be to setup an OpenVPN tunnel somewhere to go through. Maybe not pretty, but it'll work.
If you want to try that email me off list and we can set it up on my colo box.
-brian
On Aug 6, 2012, at 16:00, Sampsa Laine <sampsa at mac.com> wrote:
On 6 Aug 2012, at 20:07, Johnny Billquist wrote:
Ah well, I could go on... Suffice to say that it's not because I'm opposed to the features that a TCP connection, or DNS resolution would give, but I prioritize something that I feel confident is working to features. And doing a proper solution with all these aspects is more work than I have cared to put into it. The bridge program is a hack.
As Paul mention, pthreads would probably be a good start if you want to do something more intelligent. You need to start thinking asynchronously.
My desire for this is basically because my ISP is NAT'd to hell - I have no way of getting UDP packets back to my network, as the ISP gives me a non-routable address.
Why go with this ISP? Well it's about 3x faster than the DSL I can get in the sticks over a 3G signal, with unlimited bandwidth and usage.
But sucks for HECnet..
Sampsa
Maybe there's been a pagan revival in Uppsala, some drunken Vikings have decided to take over the University hall and drink to Odin.
But that's just my guess as a Finn.
Sampsa
On 9 Aug 2012, at 00:12, Mark Benson wrote:
I'll third that, my hash of destinations basically returns me. I read that as psilo/130.238.19.25 is not receiving my packets?
On 8 Aug 2012, at 21:28, Sampsa Laine wrote:
Same here.
On 8 Aug 2012, at 16:42, Bob Armstrong wrote:
I notice that the bridge is down again this morning. Is it just me?
Bob
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
I'll third that, my hash of destinations basically returns me. I read that as psilo/130.238.19.25 is not receiving my packets?
On 8 Aug 2012, at 21:28, Sampsa Laine wrote:
Same here.
On 8 Aug 2012, at 16:42, Bob Armstrong wrote:
I notice that the bridge is down again this morning. Is it just me?
Bob
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
