Search Results

Search found 7 results on 1 pages for 'user42055'.

Page 1/1 | 1

SSH traffic over openvpn connection freezes when I cat a file

- by user42055

I have an openvpn (version 2.1_rc15 at both ends) connection setup between two gentoo boxes using shared keys. it works fine for the most part. I use mysql, http, ftp, scp over the vpn with no problems. But when I ssh from the client to the server over the vpn, weird things happen. I can login, i can execute some commands. But if i try to run an ncurses application like top, or i try to cat a file, the connection will stall and I'll have to sever the ssh session. I can, for example, execute "echo blah; echo .; echo blah" and it will output the three lines of text over the ssh session fine. But if i execute "cat /etc/motd" the session will freeze the moment I press enter. I compiled openvpn 2.1.1 on my mac and copied over my config directory from my gentoo client. The mac connected and ssh sessions worked fine without freezing. I then compiled it on my older gentoo box (2.6.26 kernel) which I am retiring due to a dying hard drive, and ssh over it also works perfectly. Why does it fail on my brand new gentoo box ? I've tried compiling three different kernels in case it was that, but other than that there should be no difference between my older and my newer gentoo boxes that I can think of. Any suggestions on what's wrong ?

Read the article
openvpn not creating internal route for client

- by user42055

I have two openvpn clients and a server using shared keys. I have internal routes specified in the ccd directory for both clients, but when they connect, the server only creates the internal route for one of them, despite the logs saying it's creating both. Both clients and the server use the "--script-security 2" command-line option. Can anyone think of why it would do this ? My ccd files are: client1: iroute 192.168.0.0 255.255.255.0 client2: iroute 10.0.1.0 255.255.255.0 My log file shows the following (cropped): May 3 17:22:59 kino openvpn[2416]: 118.208.58.60:48730 [client1] Peer Connection Initiated with 118.208.58.60:48730 May 3 17:22:59 kino openvpn[2416]: client1/118.208.58.60:48730 OPTIONS IMPORT: reading client specific options from: ccd/client1 May 3 17:22:59 kino openvpn[2416]: client1/118.208.58.60:48730 MULTI: Learn: 192.168.150.10 -> client1/118.208.58.60:48730 May 3 17:22:59 kino openvpn[2416]: client1/118.208.58.60:48730 MULTI: primary virtual IP for client1/118.208.58.60:48730: 192.168.150.10 May 3 17:22:59 kino openvpn[2416]: client1/118.208.58.60:48730 MULTI: internal route 192.168.0.0/24 -> client1/118.208.58.60:48730 May 3 17:22:59 kino openvpn[2416]: client1/118.208.58.60:48730 MULTI: Learn: 192.168.0.0/24 -> client1/118.208.58.60:48730 May 3 17:23:01 kino openvpn[2416]: client1/118.208.58.60:48730 PUSH: Received control message: 'PUSH_REQUEST' May 3 17:23:01 kino openvpn[2416]: client1/118.208.58.60:48730 SENT CONTROL [client1]: 'PUSH_REPLY,route 192.168.150.1,topology net30,ping 10,ping-restart 120,ifconfig 192.168.150.10 192.168.150.9' (status=1) May 3 17:21:36 kino openvpn[2416]: 124.148.1.90:59277 [client2] Peer Connection Initiated with 124.148.1.90:59277 May 3 17:21:36 kino openvpn[2416]: client2/124.148.1.90:59277 OPTIONS IMPORT: reading client specific options from: ccd/client2 May 3 17:21:36 kino openvpn[2416]: client2/124.148.1.90:59277 MULTI: Learn: 192.168.150.14 -> client2/124.148.1.90:59277 May 3 17:21:36 kino openvpn[2416]: client2/124.148.1.90:59277 MULTI: primary virtual IP for client2/124.148.1.90:59277: 192.168.150.14 May 3 17:21:36 kino openvpn[2416]: client2/124.148.1.90:59277 MULTI: internal route 10.0.1.0/24 -> client2/124.148.1.90:59277 May 3 17:21:36 kino openvpn[2416]: client2/124.148.1.90:59277 MULTI: Learn: 10.0.1.0/24 -> client2/124.148.1.90:59277 May 3 17:21:39 kino openvpn[2416]: client2/124.148.1.90:59277 PUSH: Received control message: 'PUSH_REQUEST' May 3 17:21:39 kino openvpn[2416]: client2/124.148.1.90:59277 SENT CONTROL [client2]: 'PUSH_REPLY,route 192.168.150.1,topology net30,ping 10,ping-restart 120,ifconfig 192.168.150.14 192.168.150.13' (status=1) And after both clients have connected, the routing table looks like this: 192.168.150.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 203.209.167.192 0.0.0.0 255.255.255.224 U 0 0 0 eth0 192.168.150.0 192.168.150.2 255.255.255.0 UG 0 0 0 tun0 192.168.0.0 192.168.150.2 255.255.255.0 UG 0 0 0 tun0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 203.209.167.193 0.0.0.0 UG 0 0 0 eth0 As you can see, it's created the route to 192.168.0.0/24 (client1) but not to 10.0.1.0/24 (client2), even though the log says it's been created. Any suggestions why ?

Read the article
OpenVPN - client-to-client traffic working in one direction but not the other

- by user42055

I have the following VPN configuration: +------------+ +------------+ +------------+ | outpost |----------------| kino |----------------| guchuko | +------------+ +------------+ +------------+ OS: FreeBSD 6.2 OS: Gentoo 2.6.32 OS: Gentoo 2.6.33.3 Keyname: client3 Keyname: server Keyname: client1 eth0: 10.0.1.254 eth0: 203.x.x.x eth0: 192.168.0.6 tun0: 192.168.150.18 tun0: 192.168.150.1 tun0: 192.168.150.10 P-t-P: 192.166.150.17 P-t-P: 192.168.150.2 P-t-P: 192.168.150.9 Kino is the server and has client-to-client enabled. All three machines have ip forwarding enabled, by this on the gentoo boxes: net.ipv4.conf.all.forwarding = 1 And this on the FreeBSD box: net.inet.ip.forwarding: 1 In the server's "ccd" directory is the following files: client1: iroute 192.168.0.0 255.255.255.0 client3: iroute 10.0.1.0 255.255.255.0 The server config has these routes configured: push "route 192.168.0.0 255.255.255.0" push "route 10.0.1.0 255.255.255.0" route 192.168.0.0 255.255.255.0 route 10.0.1.0 255.255.255.0 Kino's routing table looks like this: 192.168.150.0 192.168.150.2 255.255.255.0 UG 0 0 0 tun0 10.0.1.0 192.168.150.2 255.255.255.0 UG 0 0 0 tun0 192.168.0.0 192.168.150.2 255.255.255.0 UG 0 0 0 tun0 192.168.150.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 Outpost's like this: 192.168.150 192.168.150.17 UGS 0 17 tun0 192.168.0 192.168.150.17 UGS 0 2 tun0 192.168.150.17 192.168.150.18 UH 3 0 tun0 And Guchuko's like this: 192.168.150.0 192.168.150.9 255.255.255.0 UG 0 0 0 tun0 10.0.1.0 192.168.150.9 255.255.255.0 UG 0 0 0 tun0 192.168.150.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 Now, the tests. Pings from Guchuko to Outpost's LAN IP work OK, as does the reverse - pings from Outpost to Guchuko's LAN IP. However... Pings from Outpost, to a machine on Guchuko's LAN work fine: .(( root@outpost )). (( 06:39 PM )) :: ~ :: # ping 192.168.0.3 PING 192.168.0.3 (192.168.0.3): 56 data bytes 64 bytes from 192.168.0.3: icmp_seq=0 ttl=63 time=462.641 ms 64 bytes from 192.168.0.3: icmp_seq=1 ttl=63 time=557.909 ms But a ping from Guchuko, to a machine on Outpost's LAN does not: .(( root@guchuko )). (( 06:43 PM )) :: ~ :: # ping 10.0.1.253 PING 10.0.1.253 (10.0.1.253) 56(84) bytes of data. --- 10.0.1.253 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2000ms Guchuko's tcpdump of tun0 shows: 18:46:27.716931 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 1, length 64 18:46:28.716715 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 2, length 64 18:46:29.716714 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 3, length 64 Outpost's tcpdump on tun0 shows: 18:44:00.333341 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 3, length 64 18:44:01.334073 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 4, length 64 18:44:02.331849 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 5, length 64 So Outpost is receiving the ICMP request destined for the machine on it's subnet, but appears not be forwarding it. Outpost has gateway_enable="YES" in its rc.conf which correctly sets net.inet.ip.forwarding to 1 as mentioned earlier. As far as I know, that's all that's required to make a FreeBSD box forward packets between interfaces. Is there something else I could be forgetting ?

Read the article
Gentoo on Mac Mini - can't get framebuffer to work

- by user42055

I have the last Gentoo on an intel mac mini with 945G graphics. I'm trying to start X (with no config) but it complains that /dev/fb0 doesn't exist. I've tried adding the following options to the kernel boot params: video=intelfb:mode=800x600-32@60,accel,hwcursor vga=761 Because I read that the fb might not be enabled unless you set a vga= option. Unfortunately the kernel doesn't recognise that option. If I changed it to vga=ask it presents me a list of about 6 text modes no greater than 80x60. In the kernel I have agpgart, drm (using i830 module) and vga text console compiled in. What am I not doing right ?

Read the article
Gentoo on Mac Mini - can't get framebuffer to work

- by user42055

I have the latest Gentoo on an intel mac mini with 945G graphics. I'm trying to start X (with no config) but it complains that /dev/fb0 doesn't exist. I've tried adding the following options to the kernel boot params: video=intelfb:mode=800x600-32@60,accel,hwcursor vga=761 Because I read that the fb might not be enabled unless you set a vga= option. Unfortunately the kernel doesn't recognise that option. If I changed it to vga=ask it presents me a list of about 6 text modes no greater than 80x60. In the kernel I have agpgart, drm (using i830 module) and vga text console compiled in. What am I not doing right ?

Read the article
Linux port-based routing using iptables/ip route

- by user42055

I have the following setup: 192.168.0.4 192.168.0.6 192.168.0.1 +-----------+ +---------+ +----------+ |WORKSTATION|------| LINUX |------| GATEWAY | +-----------+ +---------+ +----------+ 192.168.150.10 | 192.168.150.9 +---------+ | VPN | +---------+ 192.168.150.1 WORKSTATION has a default route of 192.168.0.6 LINUX has a default route of 192.168.0.1 I am trying to use the gateway as the default route, but route port 80 traffic via the VPN. Based on what I read at http://www.linuxhorizon.ro/iproute2.html I have tried this: echo "1 VPN" >> /etc/iproute2/rt_tables sysctl net.ipv4.conf.eth0.rp_filter = 0 sysctl net.ipv4.conf.tun0.rp_filter = 0 sysctl net.ipv4.conf.all.rp_filter = 0 iptables -A PREROUTING -t mangle -i eth0 -p tcp --dport 80 -j MARK --set-mark 0x1 ip route add default via 192.168.150.9 dev tun0 table VPN ip rule add from all fwmark 0x1 table VPN When I run "tcpdump -i eth0 port 80" on LINUX, and open a webpage on WORKSTATION, I don't see the traffic go through LINUX at all. When I run a ping from WORKSTATION, I get this back from some packets: 92 bytes from 192.168.0.6: Redirect Host(New addr: 192.168.0.1) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 de91 0 0000 3f 01 4ed3 192.168.0.4 139.134.2.18 Is this why my routing is not working ? Do I need to put GATEWAY and LINUX on different subnets to prevent WORKSTATION being redirected to GATEWAY ? Do I need to use NAT at all, or can I do this with routing alone (which is what I want) ?

Read the article
trying to route between two openvpn clients

- by user42055

I have two openvpn clients on the 10.0.1.0 (client1) and 192.168.0.0 (client2) subnets with the server's openvpn connection having the ip 192.168.150.1 The server has ip forwarding enabled. Currently, client1's vpn ip is 192.168.150.10 and the P-t-P ip is 192.168.150.9 I have created the following static route on client1: route add -net 10.0.1.0 netmask 255.255.255.0 gw 192.168.150.9 The routing table on client1 looks like this: Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.150.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.168.150.1 192.168.150.9 255.255.255.255 UGH 0 0 0 tun0 10.0.1.0 192.168.150.9 255.255.255.0 UG 0 0 0 tun0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 I thought this would be correct to allow traffic from client1 to reach computers on client2's network, but it does not work. Is 192.168.150.9 (the P-t-P address) the correct one to be routing through ? I tried using 192.168.150.1 but I couldn't create the route. I hope this is clear.

Read the article

1