=== November 1 2010 ===

--- Log opened Mon Nov 01 23:18:52 2010
Lastlog:
13:00 -!- nox [~user@10.81.1.233] has joined #lair
13:00 -!- Topic for #lair: LAIR chat
13:00 -!- Topic set by -Server- [] [Mon Sep 20 11:59:52 2010]
13:00 [Users #lair]
13:00 [ Ender] [ jzimmer5] [ Riptuer] [ wedge] 
13:00 [ Ian  ] [ nox     ] [ tracer ] 
13:00 -!- Irssi: #lair: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal]
13:00 -!- Irssi: Join to #lair was synced in 2 secs
13:01 < wedge> welcome back
13:01 < nox> Good afternoon
13:01 < nox> Thanks
14:00 -!- You're now known as _nox
15:57 -!- You're now known as nox
15:57 < nox> Grrrrrr
15:57 < nox> Openswan has frustrated me for now
15:57 < nox> I'll have to take a break and get back to this guy after dinner
15:58 < nox> I think I understand the theory of what needs to be done
15:59 < nox> I've compiled my own copy of strongswan
15:59 < nox> This version doesn't require kernel modifications
15:59 < nox> sweet
15:59 < nox> and it lets me enable NAT traversal
15:59 < nox> So that all works
16:00 < nox> but somewhere either in the Openswan configs or l2tp config files I missed something
16:00 < nox> The syslog doesn't even show my iPhone trying to connect
16:00 < nox> Grrrr
16:00 < nox> But I feel pretty confident that I will get it
16:01 < nox> Interesting thing- Openswan can route to OpenVPN
16:01 < nox> so we could provide an OpenSwan gateway for iOS devies and keep using OpenVPN
16:01 < nox> I think that could be cool
16:02 < nox> DSLab is joined to LAIR through an OpenVPN tunnel, right?
16:02 < nox> Anyway, just thinking about stuff
16:02 < nox> I'll be back later tonight
16:03 < nox> I think Herb is going to join in on the VPNing fun, maybe we'll get something going
16:03 < nox> Also I'm going to spend some time with the db server tonight
16:03 < nox> I think I might be pretty close with that
16:03 < nox> :)
16:03 -!- You're now known as _nox
18:07 < wedge> yes-- OpenVPN tunnel connects DSLAB and LAIR
18:36 < wedge> regarding logs... where are you trying to run openswan? on juicebar?
19:30 < _nox> I'm sticking clear of making any changes to production machines until I can prove OpenSwan
19:31 < _nox> I'm running it on Athens01
19:31 < wedge> and where is your client coming from?
19:31 < _nox> The client is my iPhone who has joined UFO
19:31 -!- You're now known as nox
19:33 < wedge> I wonder if, the reason you are not seeing any log messages, is because the server is physically not receiving any packets?
19:33 < wedge> firewall on UFO?
19:33 < nox> Yeah, that's what I'm wondering too
19:33 < nox> hmm that's a good point, I can definitely see that apache server from the iPhone
19:34 < wedge> I know if you were going through juicebar, the firewall rules WOULD block it by default
19:34 < wedge> we'd have to add a rule to specifically allow that traffic on a particular interface
19:35 < nox> But UFO is already on the inside, wouldn't that take care of the firewall?
19:35 < wedge> UFO may be running a firewall
19:36 < wedge> it is designed to by default
19:36 < nox> That's a good though, I was wondering if we could run openswan on ufo itself but I hadn't looked into that just yet
19:37 < wedge> for example, there's a setting to allow remote access to the administrative web interface from networks outside the ones it serves
19:37 < wedge> it is typically disabled by default. That is handled by its firewall.
19:38 < wedge> what type of traffic is openswan looking to pass?
19:38 < nox> http://wiki.openswan.org/index.php/Openswan/ConfFirewall
19:38 < wedge> probably something at the IP level? I seem to recall not much going on at transport level
19:38 < nox> It looks like protocol 50, 51 and some UDP
19:39 < wedge> what are we running on UFO... DD-WRT?
19:40 < wedge> ultimately, you won't want to run OpenSWAN on UFO... because all the traffic will be coming from the outside network, and hitting juicebar
19:40 < nox> UFO is running ddwrt, yup
19:41 < nox> ok, so you think the load would be too much (and unnecessary) on UFO
19:42 < wedge> I don't think it would be too much... UFO just doesn't deal with the network traffic you'd be using OpenSWAN for
19:42 < wedge> it is inside, where you want OpenSWAN intercepting outside traffic (ie juicebar's domain)
19:43 < nox> Okay
19:43 < wedge> the current suspicion is that UFO might be unintentionally blocking the traffic, preventing you from testing
19:43 < nox> I have openswan on the inside right now just to test it out
19:43 < wedge> yeah
19:43 < nox> It doesn't actually make much sense to VPN in when you're already on the inside
19:43 < nox> ;)
19:43 < wedge> but you said you weren't getting any log messages
19:43 < wedge> correct :)
19:44 < nox> correct!  I'm looking into the firewall now
19:45 < nox> hmm ok so all the firewalls are off and have been off
19:45 < nox> And all VPN passthrough settings are enabled and have been enabled
19:46 < wedge> have you tried doing a tcpdump to see what traffic might be arriving at Athens0?
19:46 < nox> not yet
19:47 < nox> What do you think this means:
19:47 < nox> Athens01 reports an address of 10.81.1.233
19:48 < nox> I can access it via that address on other machines on the network
19:48 < nox> when I ping athens01 while connected to UFO I can an address of 208.68.143.55
19:48 < nox> *I get an
19:48 < nox> But the host isn't accessible via that address
19:49 < nox> and the 10.81 address isn't reachable
19:49 < wedge> DNS settings are causing that to happen
19:49 < wedge> the 208.68....
19:49 < nox> So there's the answer from UFO athens01 isn't accessible
19:50 < wedge> I can't seem to get in to 10.81.1.233, is it using a different password?
19:51 < nox> You should see observium @ http://10.81.1.233/
19:51 < nox> It's a piece of software I was toying with but didn't work out
19:52 < wedge> I was trying to ssh into the machine as root
19:52 < wedge> if it is ubuntu, probably disabled by default
19:52 < nox> It is ubuntu
19:52 < nox> the user is called user
19:52 < nox> password is standard
19:54 < nox> I think the whole problem is that there is no path from ufo -> athens01
19:54 < wedge> hmm indeed
19:55 < wedge> yeah, ufo doesn't seem to be happy with traffic coming to it at all
19:56 < wedge> I can't ping it from juicebar, athens01, or the LAIR end of the VPN
19:56 < nox> But I can connect to it and get out to the internet
19:56 < wedge> are you able to get a console on it (ie via SSH)?
19:56 < nox> It has an IP 10.81.1.5
19:56 < nox> Err 10.81.5.1
19:58 < wedge> if you can, copy and paste: netstat -nr
19:58 < nox> It looks like the physical connection is UFO (internet port) -> dslab1 (port 19(
19:59 < nox> Working on the netstat
19:59 < nox> I'm talking to you from one machine and on UFO on another
20:00 < nox> http://gist.github.com/659081
20:01 < wedge> that's on your Mac, right?
20:01 < nox> Yup
20:01 < wedge> I need to see that for ufo itself
20:01 < nox> So shh into UFO?
20:01 < wedge> yeah
20:01 < wedge> if we have that set up
20:02 < nox> telnet is setup but netstat isn't available
20:03 < wedge> how about: ip route show
20:04 < nox> http://gist.github.com/659084
20:04 < wedge> ah
20:04 < wedge> there's our problem
20:04 < wedge> ufo is on the CSci subnet
20:04 < nox> but it's connected to port 19 on dslab1
20:06 < nox> Should I move it over to the switch where we have our workstations setup?
20:06 < nox> On that switch everyone definitely is getting an internal address
20:06 < wedge> yes
20:07 < wedge> I will admit I am puzzled by why it is getting a 137.238.8.x address
20:07 < wedge> what else is on dslab1 ?
20:07 < wedge> we're talking one of the netgear switches, right?
20:07 < nox> Yeah dslab1 is one of the netgear switches
20:08 < wedge> are other devices on the dslab1 switch getting 10.81.1.x or are they also getting 137.238.8.x addresses?
20:09 < nox> it looks like sparta is on dslab1
20:09 < nox> also sparta04 is making some bad spinny clicky noises
20:09 < nox> sounds like a sick drive
20:10 < wedge> are you sure it isn't an internal fan making contact with wires?
20:10 < wedge> Philip assembled one that did that, and I don't recall if he ever figured out which one it was to fix
20:10 < nox>  No, I just heard bad noises and came back to the keyboard
20:11 < wedge> yeah, sparta00 is definitely getting a 10.81.1.x address
20:11 < nox> alright I'll add looking into it to the whiteboard
20:11 < nox> it's not sick in any way on the monitor
20:11 < wedge> I don't see anything immediately awry on sparta04
20:11 < wedge> that's just *weird*... it shouldn't be able to work
20:11 < wedge> has ufo been reset anytime recently?
20:11 < nox> I just reset and moved UFO
20:12 < nox> reset, like the software? nope
20:12 < wedge> reset as in power cycle
20:12 < wedge> ah
20:12 < wedge> there we go
20:12 < wedge> I can ping ufo now
20:14 < nox> But now I don't get the internet through ufo
20:14 < wedge> can you give me another: ip route show
20:14 < wedge> on ufo?
20:14 < nox> Yeah on UFO
20:14 < wedge> yeah, give me another :ip route show
20:14 < wedge> for ufo
20:14 < nox> But UFO definitely sees juicebar in the routing table
20:15 < nox> Well that doesn't matter, I can see 10.81.1.233 from UFO
20:15 < nox> that's what I'm working on :)
20:15 < nox> Ok, let's try openswan
20:16 < wedge> getting internet might be a simple fix of a route addition
20:16 < nox> Oh and no luck on VPN
20:17 < wedge> try accessing the internet from your machine on UFO
20:17 < nox> Nope, the mac on UFO doesn't get to the internet
20:18 < wedge> well, no traffic is hitting juicebar
20:18 < wedge> I suspect a route problem
20:18 < wedge> if you could get me a: ip route show
20:19 < wedge> from ufo's console, we can ascertain it...improper routes could also still be preventing your OpenSWAN experiment from working
20:19 < nox> hmmm I can't post to github
20:20 < nox> What was the route command, again? I just did route but it may not be what you want
20:20 < wedge> ip route show
20:22 < nox> gist.github.com/659108
20:23 < wedge> ok, on your mac on ufo's network, try to access: http://143.66.50.18/
20:23 < wedge> tell me if you get anything
20:23 < nox> Lab46: The Wiki
20:24 < wedge> ok, networking works, DNS is broken
20:24 < wedge> on the UFO side of the network
20:25 < nox> Alright, what am I looking for?
20:25 < wedge> very weird I'm not picking up any traffic
20:26 < wedge> do me a favor, try refreshing that page
20:26 < wedge> on your mac
20:26 < wedge> just trying to pick up traffic in a tcpdump
20:26 < nox> You're still alive
20:26 < wedge> yeah... I'd check DNS Settings on UFO
20:26 < wedge> make sure the DNS Server is: 10.81.1.1
20:26 < wedge> searching dslab.lan
20:26 < wedge> domain dslab.lan
20:27 < wedge> whatever the options are called
20:27 < wedge> if you want additional DNS:
20:27 < wedge> 10.80.2.1
20:27 < wedge> 10.80.1.1
20:27 < nox> Local DNS is set to 10.81.1.1
20:28 < nox> Static DNS 1 is set to 10.81.1.1
20:28 < nox> ditto for DNS 2
20:28 < nox> DNS 3 is 10.81.2.1
20:28 < wedge> well, that doesn't exist..
20:28 < wedge> shouldn't be throwing things off though
20:28 < nox> DNS 3?
20:28 < wedge> yeah
20:28 < wedge> 10.80.2.1
20:29 < nox> Is there a 10.80.1.1?
20:29 < nox> Just curious
20:29 < wedge> yes
20:29 < wedge> 10.80.1.1
20:29 < wedge> and 10.80.2.1
20:29 < wedge> you had written 10.81.2.1
20:29 < wedge> note the 81 instead of the 80
20:29 < nox> so all DNS is in the 10.80 range
20:30 < nox> There is no 10.81.1.1?
20:30 < wedge> there is
20:30 < wedge> that's the only one in 10.81
20:30 < wedge> 10.81.1.1
20:30 < wedge> 10.80.1.1
20:30 < wedge> 10.80.2.1
20:31 < nox> Hark!
20:31 < nox> The internet
20:31 < wedge> :)
20:31 < wedge> at least one problem solved!
20:31 < nox> I changed 10.81.1.1 to 10.80.1.1 and rebooted
20:31 < nox> and then the internet worked
20:31 < nox> Why would that do it?
20:31 < wedge> why no OpenSWAN... as far as I can tell... it shouldn't be prevented from working
20:31 < wedge> might have been a stale value
20:32 < wedge> it *should* work with 10.81.1.1, that's what the rest of the DSLAB is using for DNS
20:32 < nox> Hmmm weird
20:32 < nox> but that's one problem gone
20:32 < nox> Er
20:32 < nox> maybe
20:33 < nox> Now I can't get to 10.81.1.233
20:33 < nox> through ufo
20:33 < wedge> can you ping 10.81.1.1
20:34 < wedge> on your mac
20:34 < nox> Nope
20:34 < wedge> hook me up with another: ip route show
20:34 < wedge> on ufo's console
20:34 < wedge> heh, I can't ping ufo anymore either
20:35 < nox> I can still get to the IP for the wiki
20:36 < wedge> something's not right... check and see if it is back on the CSci subnet
20:36 < nox> UFO is on the CS domain
20:36 < wedge> why, I have no idea (or how)
20:36 < nox> http://gist.github.com/659123
20:36 < wedge> big ol' W-T-F
20:36 < nox> :D
20:37 < nox> Amen to that
20:37 < wedge> I am honestly at a loss, based on what I know, this is defying the impossible
20:37 < wedge> let's try some basic debugging
20:37 < nox> okay
20:37 < wedge> on the WAN port on UFO, where is that plugged into?
20:37 < wedge> should be the DSLAB1 switch
20:37 < wedge> (or DSLAB2 switch-- some netgear internal DSLAB switch)
20:37 < nox> the WAN port is plugged into port 19 of the same switch that services all of the athens workstations
20:37 < wedge> ok
20:37 < nox> it's an unnamed DELL powerconnect
20:38 < wedge> how about the LAN ports?
20:38 < nox> Nothing going into any of them
20:38 < wedge> woah... what is an unnamed DELL powerconnect?
20:38 < wedge> the switch that services the athens workstations?
20:38 < wedge> the Dell powerconnect is OUTSIDE
20:38 < nox> It's the switch that services the athens workstations, I don't think we can connect to the switch
20:38 < nox> The switch is on the inside
20:38 < nox> the machine I'm typing on is on this switch
20:38 < wedge> did you move it to the inside?
20:39 < wedge> that switch used to be where juicebar (and bob) got their external connections
20:39 < wedge> it was configured for 137.238.7.x, and had no configuration for inside
20:39 < nox> Are you sure?  There's another Dell switch in the back
20:39 < nox> I'm on the dell switch on this athens and I have an IP of 10.81.1.233
20:39 < wedge> is it a 16-port Dell switch?
20:40 < wedge> the dumb, 16-port switch by the G5?
20:40 < nox> yes
20:40 < wedge> ok... so different Dell switch
20:40 < wedge> I thought you said it was plugged into the big 24-port Dell switch behind the video wall
20:41 < nox> It was, when we started the night
20:41 < nox> then a ways back I moved it closer to me physically
20:41 < nox> we had the same problems
20:41 < wedge> :)
20:41 < nox> :)
20:41 < wedge> ok... so that Dell 16-port switch.. does it plug into (ultimately) one of the two netgear switches?
20:42 < nox> port 17 on dslab 1
20:42 < nox> so yes
20:42 < wedge> ok
20:43 < wedge> something is hooked into the CS subnet
20:43 < nox> Didn't we have a sparta get a 137 address recently too?
20:44 < nox> Ok
20:44 < wedge> you might want to trace all the connections into that 16-port dumb Dell switch, make sure there aren't any accidental connections to the wall
20:44 < wedge> it doesn't make sense, but if there's a connection, rogue DHCP could be getting through
20:44 < wedge> and some devices getting caught up in that
20:45 < wedge> I'd expect there to be more problems if that were the case, but it is something to look for at any rate
20:45 < nox> I only see one connection to the wall in the corner by the video wall
20:45 < nox> although it's a bit of a mess
20:45 < nox> let me go look some more
20:46 < wedge> the way it should be: the ONLY connection from the wall should go to the 24-port Dell switch
20:49 < nox> Still alive?
20:49 < nox> Am I still here?
20:50 < wedge> as far as I can tell
20:50 < nox> Weird
20:50 < nox> I shouldn't be
20:50 < nox> I lost power on the switch
20:50 < nox> that this is connected to
20:50 < wedge> not necessarily the end of the world
20:50 < wedge> networking can be resilient like that
20:50 < nox> I guess, or this is heaven
20:50 < nox> but anyway
20:51 < nox> to the DELL powerconnect there was another outside connection
20:51 < nox> So there were 2!
20:51 < wedge> and you disconnected one of them, or are they both still plugged in?
20:52 < wedge> I seem to remember a white cable (once upon a time) being the one for the outside connection
20:52 < wedge> but that could easily have been changed over time
20:52 < nox> I pulled the connection from the DELL powerconnect port 3 to the wall
20:52 < wedge> ok... and we're still operational
20:52 < nox> There is still a white cable going into a mess of cables over behind the VWall
20:52 < nox> Rebooted UFO
20:52 < wedge> I'm pinging again
20:53 < nox> I get internet and I can ping node132
20:53 < wedge> so it is back
20:53 < nox> It's back
20:53 < nox> When we were cleaning the lab and setting up workstations there were a lot of people moving computer and plugging and unplugging
20:53 < nox> I'm sure this cable ended up plugged in by someone because it seemed like the right thing
20:53 < nox> heck it could have been me
20:54 < wedge> what's important is that the mystery (hopefully) has been solved
20:54 < nox> indeed!
20:55 < nox> There is now a route from the iPhone to 10.81.1.233 for http
20:55 < nox> But VPN fails :(
20:58 < nox> It's hard to know what's going on because there's so much noise on a tcpdump
20:58 < wedge> ufo stopped pinging
20:59 < nox> entirely my fault, I kicked the power cord out
20:59 < nox> It'll be back in just a second
20:59 < wedge> ok, just paranoid thinking the problem had returned
20:59 < wedge> yep, it is back
20:59 < nox> If you're working with VPN, the shared secret is cookie
21:00 < nox> the username is nsr1 and will accept any password
21:00 < wedge> ok
21:01 < wedge> where are you tcpdumping, on athens01?
21:01 < nox> Even if I'm tailing /var/log/messages I'm not seeing anything VPNish
21:01 < nox> yeah, tcpdump is on athens01
21:01 < nox> To setup the VPN I followed this guide: http://nielspeen.com/blog/2009/04/linux-l2tpipsec-with-iphone-and-mac-osx-clients/
21:01 < wedge> what is the IP of your client device?
21:01 < nox> 10.81.1.101
21:02 < nox> (iPhone)
21:02 < wedge> 1.101, or 5.101?
21:02 < nox> good catch
21:02 < nox> 10.81.5.101
21:02 < wedge> try connecting to the VPN with the iPhone
21:02 < wedge> I'm doing a tcpdump
21:03 < nox> Alright here we are
21:03 < nox> fail
21:03 < nox> Again
21:03 < wedge> yeah, seeing nothing
21:03 < nox> fail
21:04 < nox> ipsec is definitely running
21:05 < nox> As is xl2tpd
21:07 < nox> brb
21:09 < nox> back
21:12 < wedge> your iPhone is on ufo's network?
21:12 < nox> Yeah
21:12 < wedge> for server, you put in 10.81.1.233
21:13 < nox> Yup: http://picasaweb.google.com/nixterrimus/Lab#5534754249785342002
21:15 < nox> I see that ubuntu's built in firewall is deactivated
21:15 < nox> that's good
21:16 < wedge> shouldn't be preventing traffic (but you never know)--- you have nat_traversal enabld in /etc/ipsec.conf
21:16 < wedge> might want to flip that to a no and restart it
21:16 < wedge> at the moment, you're not nat traversing
21:16 < wedge> everyone has a "real" IP
21:17 < nox> I think nat_traversal is supposed to be enabled in ipsec.conf and it looks like it is
21:17 < nox> I built strongswan with the nat_traversal enabled
21:18 < nox> I think it needs to be enabled for the VPN to work, should I try it with nat_traversal off?
21:21 < wedge> yeah, nat_traversal is an option to enable openswan to work with a connection through a NAT
21:21 < nox> Alright, let's try flipping it to off and restarting strongswan
21:21 < wedge> like a roadrunner connection with only 1 IP serving a network of machines behind it
21:21 < wedge> like I said, I don't see how it could be preventing operation, but it is something out of place, so worth trying
21:22 < nox> Gotcha, won't that eventually be us when we have 1 137.238 address as an entry?
21:22 < nox> Alright, I 
21:22 < nox> Alright, I've turned it off and rebooted
21:22 < nox> and still no luck with the iPhone
21:22 < wedge> yeah, we will then
21:23 < nox> but right now, not a big deal
21:30 < nox> Ok
21:30 < nox> There is something happening
21:30 < nox> Listening on port 500 or 4500
21:30 < nox> sudo tcpdump -i eth0 -n -p udp port 500 or udp port 4500
21:30 < nox> I'll br back right back
21:42 < wedge> I'm going to head out shortly
21:42 < wedge> if you are back soonish... I'm tcpdumping with those parameters... give it a shot, I'd like to see what's happening
21:43 < nox> Alright I'm going trying to connect
21:43 < nox> and making noise
21:43 < wedge> indeed
21:44 < wedge> so traffic is being received
21:44 < wedge> and sent
21:44 < nox> yes
21:44 < wedge> did this happen before the nat_traversal?
21:44 < nox> I don't know I didn't learn about this command until just before I sent it to you
21:45 < nox> should I change the nat_traversal parameter?
21:45 < wedge> interestingly, it would appear some NAT'ing may be happening on the UFO side
21:45 < wedge> as the traffic is coming from 10.81.1.246
21:45 < wedge> which is UFO's presence on the dslab.lan 10.81.1.x network
21:46 < nox> But since ipsec is good with anyone connecting that shouldn't matter should it?
21:46 < wedge> correct
21:46 < wedge> I do wonder if traffic is being passed back to the iPhone as it should be
21:47 < wedge> are you getting any indication on the iPhone as to any level of communication?
21:47 < nox> No, it's pretty useless as an indicator
21:47 < wedge> might be worth setting up your Mac to do it
21:47 < wedge> see if it can generate you some client side log messages
21:47 < nox> it just says Connecting... and then The l2TP-VPN Server did not respond.  Try reconnecting or contact your admin, etc
21:48 < wedge> yeah, IF ufo isn't properly routing the return packets back, I could see that being an issue (needing some "firewall" rules, if only for NAT)
21:48 < wedge> but, we don't have enough information to make that determination
21:49 < wedge> trying it with your Mac, if it can produce logs, might be more telling
21:49 < wedge> hmmm
21:49 < wedge> something different
21:49 < wedge> port 1?
21:49 < nox> The mac is talking
21:49 < wedge> purely 1 way
21:50 < wedge> at least, not talking back on 500 or 4500
21:50 < wedge> two-way.... same as before... any logs on the Mac to speak of?
21:51 < nox> http://gist.github.com/659161
21:51 < nox> nothing really interesting
21:51 < nox> basically "connection failed"
21:51 < wedge> hmmm
21:53 < nox> I is in and R is return?
21:54 < wedge> could be
21:55 < wedge> how are you restarting/starting openswan?
21:55 < wedge> some /etc/init.d script?
21:55 < wedge> or something more manual?
21:55 < nox> init.d
21:55 < wedge> just xl2tpd ?
21:56 < wedge> does that handle everything?
21:56 < nox> ipsec and then xl2tpd
21:57 < wedge> try connecting again
21:58 < nox> Just tried the mac
21:58 < nox> same error messages in the log
21:58 < wedge> hmmm
21:59 < nox> the ipsec command looks interesting
21:59 -!- Irssi: Pasting 7 lines to #lair. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
21:59 < nox> sudo ipsec status
21:59 < nox> [sudo] password for user: 
21:59 < nox> 000 "L2TP": 10.81.1.233:17/1701---10.81.1.1...%any:17/%any==={0.0.0.0/0}; unrouted; eroute owner: #0
21:59 < nox> 000 "L2TP":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
21:59 < nox> 000 
21:59 < nox> Security Associations: none
21:59 < nox> Not entirely sure what the output means but it looks like there's an ipsec tunnel available
21:59 < wedge> where you seeing that?
22:00 < wedge> on the mac?
22:00 < nox> on athens01
22:00 < wedge> hey... did you look in /var/log/auth.log ?
22:00 < wedge> there's some interesting things in there about no preshared key found
22:00 < nox> Where do you see that?
22:01 < wedge> tail -f /var/log/auth.log
22:01 < wedge> and try connecting
22:01 -!- Irssi: Pasting 8 lines to #lair. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
22:01 < nox> sudo ipsec secrets
22:01 < nox> 002 forgetting secrets
22:01 < nox> 002 loading secrets from "/etc/ipsec.secrets"
22:01 < nox> 002 loading secrets from "/var/lib/strongswan/ipsec.secrets.inc"
22:01 < nox> 002   loaded private key file '/etc/ipsec.d/private/athens01Key.pem' (1675 bytes)
22:01 < nox> 002   loaded shared key for 0.0.0.0 10.81.1.223 
22:01 < nox> 002   loaded shared key for 0.0.0.0 10.81.1.233 
22:01 < nox> 003 "/etc/ipsec.secrets" line 12: PSK data malformed (input does not begin with format prefix): \342\200\234cookie"
22:01 < nox> Line 12
22:01 < nox> :)
22:01 < wedge> it's something
22:02 < nox> 10.81.1.233 %any: PSK “cookie"
22:04 < nox> after redoing the line I get
22:04 < nox> unable to start strongSwan -- fatal errors in config
22:04 < wedge> yeah, I was testing something real quick
22:05 < wedge> remove the plutodebug=yes line and save it
22:05 < wedge> I was about to do it, but it looks like you got in there
22:05 < nox> I don't see that line
22:05 < nox> Can you do it?
22:05 < wedge> yep, got it, started it
22:05 < wedge> try connecting again
22:06 < nox> Connection still fails
22:06 < nox> (mac)
22:06 < wedge> mmm.... many more interesting things though
22:07 < nox> What are you looking at?
22:07 < wedge> tail -f /var/log/auth.log /var/log/daemon.log
22:07 < wedge> both auth and daemon
22:07 < wedge> there's at least some activity now (I guess you fixed the malformed psk problem?)
22:08 < nox> maybe, what's this: Nov  1 22:07:24 athens01 charon: 07[CFG] line 12: missing ' : ' separator 
22:08 < wedge> that's a good one
22:08 < wedge> we'd need to find the charon config
22:08 < wedge> where-ever that is
22:09 < nox> Also no connection has been authorized with policy=PSK
22:09 < wedge> I just glanced at /etc/ipsec.conf and /etc/xl2tpd/xl2tpd.conf ... nothing that appears to be missing a ':' on or around line 12
22:09 < wedge> the no authorized connection is a good sign though
22:09 < wedge> it means it is at least trying things
22:09 < wedge> we'd need to look at figuring out how to authorize something
22:10 < nox> Right now it's authorizing by shared secret and charon config
22:10 < nox> err
22:10 < nox> /etc/xl2tpd/l2tp-secrets:
22:10 < nox> not charon config
22:10 < wedge> all blank?
22:11 < nox> Well that's a problem
22:11 < wedge> indeed
22:11 < nox> I added a user
22:12 < nox> * **       *       nsr1    *
22:13 < nox> Maybe I need to restart ipsec
22:13 < wedge> give it a shot
22:13 < nox> More progress!
22:14 < wedge> indeed
22:14 < nox> This looks like good news: Nov  1 22:13:32 athens01 pluto[23823]: "L2TP"[2] 10.81.1.246 #2: IPsec SA established {ESP=>0x085175f8 <0xb4dde234}
22:14 < wedge> aye
22:15 < wedge> however, I must be off for now
22:15 < wedge> at least it is going more, if in fits and starts
22:15 < nox> Nov  1 22:15:21 athens01 pluto[23823]: packet from 10.81.1.246:1: initial Main Mode message received on 10.81.1.233:500 but no connection has been authorized with policy=PSK
22:15 < wedge> try googling some of that
22:15 < wedge> I did earlier and there were results
22:16 < wedge> might have to cherry pick a bit to find something useful
22:16 < nox> but in /etc/ipsec.conf:
22:16 < nox> conn L2TP authby=psk pfs=no
22:16 < nox> key phrase authby=psk
22:16 < wedge> maybe there is another component still missing?
22:17 < wedge> good luck!
22:17 < nox> Thanks, we're closer
22:17 < nox> :)
22:19 < nox> YES!!!
22:19 < nox> I'm conneted
22:19 < nox> with a weird IP
22:19 < nox> but anyway
22:20 < nox> The key was setting no connection has been authorized  with policy=PSK
22:20 < nox> I'm connected with both my Mac and my iPhone!
22:20 < nox> haha!
22:21 < nox> I'm not sure if you just headed out but we're in, it's working
22:22 < nox> Phase one - Test OpenSwan: Complete!
22:23 < nox> Probably the nat traversal had to be turned on because I compiled strongswan with that option
22:34 < nox> Phase two: This whole setup needs to move to a dedicated computer with two ethernet ports, right?
22:35 < nox> Then get that working, then to work on LDAP as an authentication scheme
22:35 < nox> Sweet!
22:36 < nox> I'm pleased with the progress we've made tonight, now I'm going to work on my WEP research for a couple of hours
22:36 -!- You're now known as _nox
23:15 < _nox> Work in Progress: http://www.offbyone.lan/user/nsr1/open_swan_vpn
End of Lastlog
Lastlog:
13:00 -!- nox [~user@10.81.1.233] has joined #lair
13:00 -!- Topic for #lair: LAIR chat
13:00 -!- Topic set by -Server- [] [Mon Sep 20 11:59:52 2010]
13:00 [Users #lair]
13:00 [ Ender] [ jzimmer5] [ Riptuer] [ wedge] 
13:00 [ Ian  ] [ nox     ] [ tracer ] 
13:00 -!- Irssi: #lair: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal]
13:00 -!- Irssi: Join to #lair was synced in 2 secs
13:01 < wedge> welcome back
13:01 < nox> Good afternoon
13:01 < nox> Thanks
14:00 -!- You're now known as _nox
15:57 -!- You're now known as nox
15:57 < nox> Grrrrrr
15:57 < nox> Openswan has frustrated me for now
15:57 < nox> I'll have to take a break and get back to this guy after dinner
15:58 < nox> I think I understand the theory of what needs to be done
15:59 < nox> I've compiled my own copy of strongswan
15:59 < nox> This version doesn't require kernel modifications
15:59 < nox> sweet
15:59 < nox> and it lets me enable NAT traversal
15:59 < nox> So that all works
16:00 < nox> but somewhere either in the Openswan configs or l2tp config files I missed something
16:00 < nox> The syslog doesn't even show my iPhone trying to connect
16:00 < nox> Grrrr
16:00 < nox> But I feel pretty confident that I will get it
16:01 < nox> Interesting thing- Openswan can route to OpenVPN
16:01 < nox> so we could provide an OpenSwan gateway for iOS devies and keep using OpenVPN
16:01 < nox> I think that could be cool
16:02 < nox> DSLab is joined to LAIR through an OpenVPN tunnel, right?
16:02 < nox> Anyway, just thinking about stuff
16:02 < nox> I'll be back later tonight
16:03 < nox> I think Herb is going to join in on the VPNing fun, maybe we'll get something going
16:03 < nox> Also I'm going to spend some time with the db server tonight
16:03 < nox> I think I might be pretty close with that
16:03 < nox> :)
16:03 -!- You're now known as _nox
18:07 < wedge> yes-- OpenVPN tunnel connects DSLAB and LAIR
18:36 < wedge> regarding logs... where are you trying to run openswan? on juicebar?
19:30 < _nox> I'm sticking clear of making any changes to production machines until I can prove OpenSwan
19:31 < _nox> I'm running it on Athens01
19:31 < wedge> and where is your client coming from?
19:31 < _nox> The client is my iPhone who has joined UFO
19:31 -!- You're now known as nox
19:33 < wedge> I wonder if, the reason you are not seeing any log messages, is because the server is physically not receiving any packets?
19:33 < wedge> firewall on UFO?
19:33 < nox> Yeah, that's what I'm wondering too
19:33 < nox> hmm that's a good point, I can definitely see that apache server from the iPhone
19:34 < wedge> I know if you were going through juicebar, the firewall rules WOULD block it by default
19:34 < wedge> we'd have to add a rule to specifically allow that traffic on a particular interface
19:35 < nox> But UFO is already on the inside, wouldn't that take care of the firewall?
19:35 < wedge> UFO may be running a firewall
19:36 < wedge> it is designed to by default
19:36 < nox> That's a good though, I was wondering if we could run openswan on ufo itself but I hadn't looked into that just yet
19:37 < wedge> for example, there's a setting to allow remote access to the administrative web interface from networks outside the ones it serves
19:37 < wedge> it is typically disabled by default. That is handled by its firewall.
19:38 < wedge> what type of traffic is openswan looking to pass?
19:38 < nox> http://wiki.openswan.org/index.php/Openswan/ConfFirewall
19:38 < wedge> probably something at the IP level? I seem to recall not much going on at transport level
19:38 < nox> It looks like protocol 50, 51 and some UDP
19:39 < wedge> what are we running on UFO... DD-WRT?
19:40 < wedge> ultimately, you won't want to run OpenSWAN on UFO... because all the traffic will be coming from the outside network, and hitting juicebar
19:40 < nox> UFO is running ddwrt, yup
19:41 < nox> ok, so you think the load would be too much (and unnecessary) on UFO
19:42 < wedge> I don't think it would be too much... UFO just doesn't deal with the network traffic you'd be using OpenSWAN for
19:42 < wedge> it is inside, where you want OpenSWAN intercepting outside traffic (ie juicebar's domain)
19:43 < nox> Okay
19:43 < wedge> the current suspicion is that UFO might be unintentionally blocking the traffic, preventing you from testing
19:43 < nox> I have openswan on the inside right now just to test it out
19:43 < wedge> yeah
19:43 < nox> It doesn't actually make much sense to VPN in when you're already on the inside
19:43 < nox> ;)
19:43 < wedge> but you said you weren't getting any log messages
19:43 < wedge> correct :)
19:44 < nox> correct!  I'm looking into the firewall now
19:45 < nox> hmm ok so all the firewalls are off and have been off
19:45 < nox> And all VPN passthrough settings are enabled and have been enabled
19:46 < wedge> have you tried doing a tcpdump to see what traffic might be arriving at Athens0?
19:46 < nox> not yet
19:47 < nox> What do you think this means:
19:47 < nox> Athens01 reports an address of 10.81.1.233
19:48 < nox> I can access it via that address on other machines on the network
19:48 < nox> when I ping athens01 while connected to UFO I can an address of 208.68.143.55
19:48 < nox> *I get an
19:48 < nox> But the host isn't accessible via that address
19:49 < nox> and the 10.81 address isn't reachable
19:49 < wedge> DNS settings are causing that to happen
19:49 < wedge> the 208.68....
19:49 < nox> So there's the answer from UFO athens01 isn't accessible
19:50 < wedge> I can't seem to get in to 10.81.1.233, is it using a different password?
19:51 < nox> You should see observium @ http://10.81.1.233/
19:51 < nox> It's a piece of software I was toying with but didn't work out
19:52 < wedge> I was trying to ssh into the machine as root
19:52 < wedge> if it is ubuntu, probably disabled by default
19:52 < nox> It is ubuntu
19:52 < nox> the user is called user
19:52 < nox> password is standard
19:54 < nox> I think the whole problem is that there is no path from ufo -> athens01
19:54 < wedge> hmm indeed
19:55 < wedge> yeah, ufo doesn't seem to be happy with traffic coming to it at all
19:56 < wedge> I can't ping it from juicebar, athens01, or the LAIR end of the VPN
19:56 < nox> But I can connect to it and get out to the internet
19:56 < wedge> are you able to get a console on it (ie via SSH)?
19:56 < nox> It has an IP 10.81.1.5
19:56 < nox> Err 10.81.5.1
19:58 < wedge> if you can, copy and paste: netstat -nr
19:58 < nox> It looks like the physical connection is UFO (internet port) -> dslab1 (port 19(
19:59 < nox> Working on the netstat
19:59 < nox> I'm talking to you from one machine and on UFO on another
20:00 < nox> http://gist.github.com/659081
20:01 < wedge> that's on your Mac, right?
20:01 < nox> Yup
20:01 < wedge> I need to see that for ufo itself
20:01 < nox> So shh into UFO?
20:01 < wedge> yeah
20:01 < wedge> if we have that set up
20:02 < nox> telnet is setup but netstat isn't available
20:03 < wedge> how about: ip route show
20:04 < nox> http://gist.github.com/659084
20:04 < wedge> ah
20:04 < wedge> there's our problem
20:04 < wedge> ufo is on the CSci subnet
20:04 < nox> but it's connected to port 19 on dslab1
20:06 < nox> Should I move it over to the switch where we have our workstations setup?
20:06 < nox> On that switch everyone definitely is getting an internal address
20:06 < wedge> yes
20:07 < wedge> I will admit I am puzzled by why it is getting a 137.238.8.x address
20:07 < wedge> what else is on dslab1 ?
20:07 < wedge> we're talking one of the netgear switches, right?
20:07 < nox> Yeah dslab1 is one of the netgear switches
20:08 < wedge> are other devices on the dslab1 switch getting 10.81.1.x or are they also getting 137.238.8.x addresses?
20:09 < nox> it looks like sparta is on dslab1
20:09 < nox> also sparta04 is making some bad spinny clicky noises
20:09 < nox> sounds like a sick drive
20:10 < wedge> are you sure it isn't an internal fan making contact with wires?
20:10 < wedge> Philip assembled one that did that, and I don't recall if he ever figured out which one it was to fix
20:10 < nox>  No, I just heard bad noises and came back to the keyboard
20:11 < wedge> yeah, sparta00 is definitely getting a 10.81.1.x address
20:11 < nox> alright I'll add looking into it to the whiteboard
20:11 < nox> it's not sick in any way on the monitor
20:11 < wedge> I don't see anything immediately awry on sparta04
20:11 < wedge> that's just *weird*... it shouldn't be able to work
20:11 < wedge> has ufo been reset anytime recently?
20:11 < nox> I just reset and moved UFO
20:12 < nox> reset, like the software? nope
20:12 < wedge> reset as in power cycle
20:12 < wedge> ah
20:12 < wedge> there we go
20:12 < wedge> I can ping ufo now
20:14 < nox> But now I don't get the internet through ufo
20:14 < wedge> can you give me another: ip route show
20:14 < wedge> on ufo?
20:14 < nox> Yeah on UFO
20:14 < wedge> yeah, give me another :ip route show
20:14 < wedge> for ufo
20:14 < nox> But UFO definitely sees juicebar in the routing table
20:15 < nox> Well that doesn't matter, I can see 10.81.1.233 from UFO
20:15 < nox> that's what I'm working on :)
20:15 < nox> Ok, let's try openswan
20:16 < wedge> getting internet might be a simple fix of a route addition
20:16 < nox> Oh and no luck on VPN
20:17 < wedge> try accessing the internet from your machine on UFO
20:17 < nox> Nope, the mac on UFO doesn't get to the internet
20:18 < wedge> well, no traffic is hitting juicebar
20:18 < wedge> I suspect a route problem
20:18 < wedge> if you could get me a: ip route show
20:19 < wedge> from ufo's console, we can ascertain it...improper routes could also still be preventing your OpenSWAN experiment from working
20:19 < nox> hmmm I can't post to github
20:20 < nox> What was the route command, again? I just did route but it may not be what you want
20:20 < wedge> ip route show
20:22 < nox> gist.github.com/659108
20:23 < wedge> ok, on your mac on ufo's network, try to access: http://143.66.50.18/
20:23 < wedge> tell me if you get anything
20:23 < nox> Lab46: The Wiki
20:24 < wedge> ok, networking works, DNS is broken
20:24 < wedge> on the UFO side of the network
20:25 < nox> Alright, what am I looking for?
20:25 < wedge> very weird I'm not picking up any traffic
20:26 < wedge> do me a favor, try refreshing that page
20:26 < wedge> on your mac
20:26 < wedge> just trying to pick up traffic in a tcpdump
20:26 < nox> You're still alive
20:26 < wedge> yeah... I'd check DNS Settings on UFO
20:26 < wedge> make sure the DNS Server is: 10.81.1.1
20:26 < wedge> searching dslab.lan
20:26 < wedge> domain dslab.lan
20:27 < wedge> whatever the options are called
20:27 < wedge> if you want additional DNS:
20:27 < wedge> 10.80.2.1
20:27 < wedge> 10.80.1.1
20:27 < nox> Local DNS is set to 10.81.1.1
20:28 < nox> Static DNS 1 is set to 10.81.1.1
20:28 < nox> ditto for DNS 2
20:28 < nox> DNS 3 is 10.81.2.1
20:28 < wedge> well, that doesn't exist..
20:28 < wedge> shouldn't be throwing things off though
20:28 < nox> DNS 3?
20:28 < wedge> yeah
20:28 < wedge> 10.80.2.1
20:29 < nox> Is there a 10.80.1.1?
20:29 < nox> Just curious
20:29 < wedge> yes
20:29 < wedge> 10.80.1.1
20:29 < wedge> and 10.80.2.1
20:29 < wedge> you had written 10.81.2.1
20:29 < wedge> note the 81 instead of the 80
20:29 < nox> so all DNS is in the 10.80 range
20:30 < nox> There is no 10.81.1.1?
20:30 < wedge> there is
20:30 < wedge> that's the only one in 10.81
20:30 < wedge> 10.81.1.1
20:30 < wedge> 10.80.1.1
20:30 < wedge> 10.80.2.1
20:31 < nox> Hark!
20:31 < nox> The internet
20:31 < wedge> :)
20:31 < wedge> at least one problem solved!
20:31 < nox> I changed 10.81.1.1 to 10.80.1.1 and rebooted
20:31 < nox> and then the internet worked
20:31 < nox> Why would that do it?
20:31 < wedge> why no OpenSWAN... as far as I can tell... it shouldn't be prevented from working
20:31 < wedge> might have been a stale value
20:32 < wedge> it *should* work with 10.81.1.1, that's what the rest of the DSLAB is using for DNS
20:32 < nox> Hmmm weird
20:32 < nox> but that's one problem gone
20:32 < nox> Er
20:32 < nox> maybe
20:33 < nox> Now I can't get to 10.81.1.233
20:33 < nox> through ufo
20:33 < wedge> can you ping 10.81.1.1
20:34 < wedge> on your mac
20:34 < nox> Nope
20:34 < wedge> hook me up with another: ip route show
20:34 < wedge> on ufo's console
20:34 < wedge> heh, I can't ping ufo anymore either
20:35 < nox> I can still get to the IP for the wiki
20:36 < wedge> something's not right... check and see if it is back on the CSci subnet
20:36 < nox> UFO is on the CS domain
20:36 < wedge> why, I have no idea (or how)
20:36 < nox> http://gist.github.com/659123
20:36 < wedge> big ol' W-T-F
20:36 < nox> :D
20:37 < nox> Amen to that
20:37 < wedge> I am honestly at a loss, based on what I know, this is defying the impossible
20:37 < wedge> let's try some basic debugging
20:37 < nox> okay
20:37 < wedge> on the WAN port on UFO, where is that plugged into?
20:37 < wedge> should be the DSLAB1 switch
20:37 < wedge> (or DSLAB2 switch-- some netgear internal DSLAB switch)
20:37 < nox> the WAN port is plugged into port 19 of the same switch that services all of the athens workstations
20:37 < wedge> ok
20:37 < nox> it's an unnamed DELL powerconnect
20:38 < wedge> how about the LAN ports?
20:38 < nox> Nothing going into any of them
20:38 < wedge> woah... what is an unnamed DELL powerconnect?
20:38 < wedge> the switch that services the athens workstations?
20:38 < wedge> the Dell powerconnect is OUTSIDE
20:38 < nox> It's the switch that services the athens workstations, I don't think we can connect to the switch
20:38 < nox> The switch is on the inside
20:38 < nox> the machine I'm typing on is on this switch
20:38 < wedge> did you move it to the inside?
20:39 < wedge> that switch used to be where juicebar (and bob) got their external connections
20:39 < wedge> it was configured for 137.238.7.x, and had no configuration for inside
20:39 < nox> Are you sure?  There's another Dell switch in the back
20:39 < nox> I'm on the dell switch on this athens and I have an IP of 10.81.1.233
20:39 < wedge> is it a 16-port Dell switch?
20:40 < wedge> the dumb, 16-port switch by the G5?
20:40 < nox> yes
20:40 < wedge> ok... so different Dell switch
20:40 < wedge> I thought you said it was plugged into the big 24-port Dell switch behind the video wall
20:41 < nox> It was, when we started the night
20:41 < nox> then a ways back I moved it closer to me physically
20:41 < nox> we had the same problems
20:41 < wedge> :)
20:41 < nox> :)
20:41 < wedge> ok... so that Dell 16-port switch.. does it plug into (ultimately) one of the two netgear switches?
20:42 < nox> port 17 on dslab 1
20:42 < nox> so yes
20:42 < wedge> ok
20:43 < wedge> something is hooked into the CS subnet
20:43 < nox> Didn't we have a sparta get a 137 address recently too?
20:44 < nox> Ok
20:44 < wedge> you might want to trace all the connections into that 16-port dumb Dell switch, make sure there aren't any accidental connections to the wall
20:44 < wedge> it doesn't make sense, but if there's a connection, rogue DHCP could be getting through
20:44 < wedge> and some devices getting caught up in that
20:45 < wedge> I'd expect there to be more problems if that were the case, but it is something to look for at any rate
20:45 < nox> I only see one connection to the wall in the corner by the video wall
20:45 < nox> although it's a bit of a mess
20:45 < nox> let me go look some more
20:46 < wedge> the way it should be: the ONLY connection from the wall should go to the 24-port Dell switch
20:49 < nox> Still alive?
20:49 < nox> Am I still here?
20:50 < wedge> as far as I can tell
20:50 < nox> Weird
20:50 < nox> I shouldn't be
20:50 < nox> I lost power on the switch
20:50 < nox> that this is connected to
20:50 < wedge> not necessarily the end of the world
20:50 < wedge> networking can be resilient like that
20:50 < nox> I guess, or this is heaven
20:50 < nox> but anyway
20:51 < nox> to the DELL powerconnect there was another outside connection
20:51 < nox> So there were 2!
20:51 < wedge> and you disconnected one of them, or are they both still plugged in?
20:52 < wedge> I seem to remember a white cable (once upon a time) being the one for the outside connection
20:52 < wedge> but that could easily have been changed over time
20:52 < nox> I pulled the connection from the DELL powerconnect port 3 to the wall
20:52 < wedge> ok... and we're still operational
20:52 < nox> There is still a white cable going into a mess of cables over behind the VWall
20:52 < nox> Rebooted UFO
20:52 < wedge> I'm pinging again
20:53 < nox> I get internet and I can ping node132
20:53 < wedge> so it is back
20:53 < nox> It's back
20:53 < nox> When we were cleaning the lab and setting up workstations there were a lot of people moving computer and plugging and unplugging
20:53 < nox> I'm sure this cable ended up plugged in by someone because it seemed like the right thing
20:53 < nox> heck it could have been me
20:54 < wedge> what's important is that the mystery (hopefully) has been solved
20:54 < nox> indeed!
20:55 < nox> There is now a route from the iPhone to 10.81.1.233 for http
20:55 < nox> But VPN fails :(
20:58 < nox> It's hard to know what's going on because there's so much noise on a tcpdump
20:58 < wedge> ufo stopped pinging
20:59 < nox> entirely my fault, I kicked the power cord out
20:59 < nox> It'll be back in just a second
20:59 < wedge> ok, just paranoid thinking the problem had returned
20:59 < wedge> yep, it is back
20:59 < nox> If you're working with VPN, the shared secret is cookie
21:00 < nox> the username is nsr1 and will accept any password
21:00 < wedge> ok
21:01 < wedge> where are you tcpdumping, on athens01?
21:01 < nox> Even if I'm tailing /var/log/messages I'm not seeing anything VPNish
21:01 < nox> yeah, tcpdump is on athens01
21:01 < nox> To setup the VPN I followed this guide: http://nielspeen.com/blog/2009/04/linux-l2tpipsec-with-iphone-and-mac-osx-clients/
21:01 < wedge> what is the IP of your client device?
21:01 < nox> 10.81.1.101
21:02 < nox> (iPhone)
21:02 < wedge> 1.101, or 5.101?
21:02 < nox> good catch
21:02 < nox> 10.81.5.101
21:02 < wedge> try connecting to the VPN with the iPhone
21:02 < wedge> I'm doing a tcpdump
21:03 < nox> Alright here we are
21:03 < nox> fail
21:03 < nox> Again
21:03 < wedge> yeah, seeing nothing
21:03 < nox> fail
21:04 < nox> ipsec is definitely running
21:05 < nox> As is xl2tpd
21:07 < nox> brb
21:09 < nox> back
21:12 < wedge> your iPhone is on ufo's network?
21:12 < nox> Yeah
21:12 < wedge> for server, you put in 10.81.1.233
21:13 < nox> Yup: http://picasaweb.google.com/nixterrimus/Lab#5534754249785342002
21:15 < nox> I see that ubuntu's built in firewall is deactivated
21:15 < nox> that's good
21:16 < wedge> shouldn't be preventing traffic (but you never know)--- you have nat_traversal enabld in /etc/ipsec.conf
21:16 < wedge> might want to flip that to a no and restart it
21:16 < wedge> at the moment, you're not nat traversing
21:16 < wedge> everyone has a "real" IP
21:17 < nox> I think nat_traversal is supposed to be enabled in ipsec.conf and it looks like it is
21:17 < nox> I built strongswan with the nat_traversal enabled
21:18 < nox> I think it needs to be enabled for the VPN to work, should I try it with nat_traversal off?
21:21 < wedge> yeah, nat_traversal is an option to enable openswan to work with a connection through a NAT
21:21 < nox> Alright, let's try flipping it to off and restarting strongswan
21:21 < wedge> like a roadrunner connection with only 1 IP serving a network of machines behind it
21:21 < wedge> like I said, I don't see how it could be preventing operation, but it is something out of place, so worth trying
21:22 < nox> Gotcha, won't that eventually be us when we have 1 137.238 address as an entry?
21:22 < nox> Alright, I 
21:22 < nox> Alright, I've turned it off and rebooted
21:22 < nox> and still no luck with the iPhone
21:22 < wedge> yeah, we will then
21:23 < nox> but right now, not a big deal
21:30 < nox> Ok
21:30 < nox> There is something happening
21:30 < nox> Listening on port 500 or 4500
21:30 < nox> sudo tcpdump -i eth0 -n -p udp port 500 or udp port 4500
21:30 < nox> I'll br back right back
21:42 < wedge> I'm going to head out shortly
21:42 < wedge> if you are back soonish... I'm tcpdumping with those parameters... give it a shot, I'd like to see what's happening
21:43 < nox> Alright I'm going trying to connect
21:43 < nox> and making noise
21:43 < wedge> indeed
21:44 < wedge> so traffic is being received
21:44 < wedge> and sent
21:44 < nox> yes
21:44 < wedge> did this happen before the nat_traversal?
21:44 < nox> I don't know I didn't learn about this command until just before I sent it to you
21:45 < nox> should I change the nat_traversal parameter?
21:45 < wedge> interestingly, it would appear some NAT'ing may be happening on the UFO side
21:45 < wedge> as the traffic is coming from 10.81.1.246
21:45 < wedge> which is UFO's presence on the dslab.lan 10.81.1.x network
21:46 < nox> But since ipsec is good with anyone connecting that shouldn't matter should it?
21:46 < wedge> correct
21:46 < wedge> I do wonder if traffic is being passed back to the iPhone as it should be
21:47 < wedge> are you getting any indication on the iPhone as to any level of communication?
21:47 < nox> No, it's pretty useless as an indicator
21:47 < wedge> might be worth setting up your Mac to do it
21:47 < wedge> see if it can generate you some client side log messages
21:47 < nox> it just says Connecting... and then The l2TP-VPN Server did not respond.  Try reconnecting or contact your admin, etc
21:48 < wedge> yeah, IF ufo isn't properly routing the return packets back, I could see that being an issue (needing some "firewall" rules, if only for NAT)
21:48 < wedge> but, we don't have enough information to make that determination
21:49 < wedge> trying it with your Mac, if it can produce logs, might be more telling
21:49 < wedge> hmmm
21:49 < wedge> something different
21:49 < wedge> port 1?
21:49 < nox> The mac is talking
21:49 < wedge> purely 1 way
21:50 < wedge> at least, not talking back on 500 or 4500
21:50 < wedge> two-way.... same as before... any logs on the Mac to speak of?
21:51 < nox> http://gist.github.com/659161
21:51 < nox> nothing really interesting
21:51 < nox> basically "connection failed"
21:51 < wedge> hmmm
21:53 < nox> I is in and R is return?
21:54 < wedge> could be
21:55 < wedge> how are you restarting/starting openswan?
21:55 < wedge> some /etc/init.d script?
21:55 < wedge> or something more manual?
21:55 < nox> init.d
21:55 < wedge> just xl2tpd ?
21:56 < wedge> does that handle everything?
21:56 < nox> ipsec and then xl2tpd
21:57 < wedge> try connecting again
21:58 < nox> Just tried the mac
21:58 < nox> same error messages in the log
21:58 < wedge> hmmm
21:59 < nox> the ipsec command looks interesting
21:59 -!- Irssi: Pasting 7 lines to #lair. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
21:59 < nox> sudo ipsec status
21:59 < nox> [sudo] password for user: 
21:59 < nox> 000 "L2TP": 10.81.1.233:17/1701---10.81.1.1...%any:17/%any==={0.0.0.0/0}; unrouted; eroute owner: #0
21:59 < nox> 000 "L2TP":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
21:59 < nox> 000 
21:59 < nox> Security Associations: none
21:59 < nox> Not entirely sure what the output means but it looks like there's an ipsec tunnel available
21:59 < wedge> where you seeing that?
22:00 < wedge> on the mac?
22:00 < nox> on athens01
22:00 < wedge> hey... did you look in /var/log/auth.log ?
22:00 < wedge> there's some interesting things in there about no preshared key found
22:00 < nox> Where do you see that?
22:01 < wedge> tail -f /var/log/auth.log
22:01 < wedge> and try connecting
22:01 -!- Irssi: Pasting 8 lines to #lair. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
22:01 < nox> sudo ipsec secrets
22:01 < nox> 002 forgetting secrets
22:01 < nox> 002 loading secrets from "/etc/ipsec.secrets"
22:01 < nox> 002 loading secrets from "/var/lib/strongswan/ipsec.secrets.inc"
22:01 < nox> 002   loaded private key file '/etc/ipsec.d/private/athens01Key.pem' (1675 bytes)
22:01 < nox> 002   loaded shared key for 0.0.0.0 10.81.1.223 
22:01 < nox> 002   loaded shared key for 0.0.0.0 10.81.1.233 
22:01 < nox> 003 "/etc/ipsec.secrets" line 12: PSK data malformed (input does not begin with format prefix): \342\200\234cookie"
22:01 < nox> Line 12
22:01 < nox> :)
22:01 < wedge> it's something
22:02 < nox> 10.81.1.233 %any: PSK “cookie"
22:04 < nox> after redoing the line I get
22:04 < nox> unable to start strongSwan -- fatal errors in config
22:04 < wedge> yeah, I was testing something real quick
22:05 < wedge> remove the plutodebug=yes line and save it
22:05 < wedge> I was about to do it, but it looks like you got in there
22:05 < nox> I don't see that line
22:05 < nox> Can you do it?
22:05 < wedge> yep, got it, started it
22:05 < wedge> try connecting again
22:06 < nox> Connection still fails
22:06 < nox> (mac)
22:06 < wedge> mmm.... many more interesting things though
22:07 < nox> What are you looking at?
22:07 < wedge> tail -f /var/log/auth.log /var/log/daemon.log
22:07 < wedge> both auth and daemon
22:07 < wedge> there's at least some activity now (I guess you fixed the malformed psk problem?)
22:08 < nox> maybe, what's this: Nov  1 22:07:24 athens01 charon: 07[CFG] line 12: missing ' : ' separator 
22:08 < wedge> that's a good one
22:08 < wedge> we'd need to find the charon config
22:08 < wedge> where-ever that is
22:09 < nox> Also no connection has been authorized with policy=PSK
22:09 < wedge> I just glanced at /etc/ipsec.conf and /etc/xl2tpd/xl2tpd.conf ... nothing that appears to be missing a ':' on or around line 12
22:09 < wedge> the no authorized connection is a good sign though
22:09 < wedge> it means it is at least trying things
22:09 < wedge> we'd need to look at figuring out how to authorize something
22:10 < nox> Right now it's authorizing by shared secret and charon config
22:10 < nox> err
22:10 < nox> /etc/xl2tpd/l2tp-secrets:
22:10 < nox> not charon config
22:10 < wedge> all blank?
22:11 < nox> Well that's a problem
22:11 < wedge> indeed
22:11 < nox> I added a user
22:12 < nox> * **       *       nsr1    *
22:13 < nox> Maybe I need to restart ipsec
22:13 < wedge> give it a shot
22:13 < nox> More progress!
22:14 < wedge> indeed
22:14 < nox> This looks like good news: Nov  1 22:13:32 athens01 pluto[23823]: "L2TP"[2] 10.81.1.246 #2: IPsec SA established {ESP=>0x085175f8 <0xb4dde234}
22:14 < wedge> aye
22:15 < wedge> however, I must be off for now
22:15 < wedge> at least it is going more, if in fits and starts
22:15 < nox> Nov  1 22:15:21 athens01 pluto[23823]: packet from 10.81.1.246:1: initial Main Mode message received on 10.81.1.233:500 but no connection has been authorized with policy=PSK
22:15 < wedge> try googling some of that
22:15 < wedge> I did earlier and there were results
22:16 < wedge> might have to cherry pick a bit to find something useful
22:16 < nox> but in /etc/ipsec.conf:
22:16 < nox> conn L2TP authby=psk pfs=no
22:16 < nox> key phrase authby=psk
22:16 < wedge> maybe there is another component still missing?
22:17 < wedge> good luck!
22:17 < nox> Thanks, we're closer
22:17 < nox> :)
22:19 < nox> YES!!!
22:19 < nox> I'm conneted
22:19 < nox> with a weird IP
22:19 < nox> but anyway
22:20 < nox> The key was setting no connection has been authorized  with policy=PSK
22:20 < nox> I'm connected with both my Mac and my iPhone!
22:20 < nox> haha!
22:21 < nox> I'm not sure if you just headed out but we're in, it's working
22:22 < nox> Phase one - Test OpenSwan: Complete!
22:23 < nox> Probably the nat traversal had to be turned on because I compiled strongswan with that option
22:34 < nox> Phase two: This whole setup needs to move to a dedicated computer with two ethernet ports, right?
22:35 < nox> Then get that working, then to work on LDAP as an authentication scheme
22:35 < nox> Sweet!
22:36 < nox> I'm pleased with the progress we've made tonight, now I'm going to work on my WEP research for a couple of hours
22:36 -!- You're now known as _nox
23:15 < _nox> Work in Progress: http://www.offbyone.lan/user/nsr1/open_swan_vpn
End of Lastlog