Jump to content


  • Content Count

  • Joined

  • Last visited

About monachus

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That's not fair. They'll support the product, but you're using open source software, and you're responsible for supporting it. There's no significant difference in the underlying functionality between SD and 3G that would affect your OpenVPN configuration. You haven't given enough information to allow anyone to do any troubleshooting. You said, "I did something, and it doesn't work. Help me." If you'd like to get people to respond, post enough information to allow someone else to understand or duplicate the issue. Some things to ask: Is your VPN up? How do you know? Have you checked the logs on both sides? Anything interesting? How do you have it configured? Routed? Bridged? Are the routes configured properly? You said "firewall," and the response you're getting (destination port unreachable) sounds like firewall interference. If you followed the steps in the video that someone else said fixed this error, and if you still have the error, have you tried opening access completely? Are your zones and interfaces named correctly? Have you run tcpdump on both sides to see if the traffic is routed over the VPN or if it dies locally, remotely, and on what interface? You might also get better visibility and assistance if you start a new thread.
  2. If your FQDN resolves to a public IP, and you can still reach that when the VPN is up, it sounds like all of your Internet traffic is being routed over the VPN. You probably don't want that (or maybe you do). If you do, check that your OpenVPN AS system is configured to NAT traffic from your VPN network and that it has IP forwarding enabled. OVAS _should_ do this for you with its rules, but check anyway. You can use tcpdump to see if traffic from your client is leaving the VPN server without being NATted first, or if it's leaving at all. On the other hand, if this is _not_ what you want, go into the admin area of AS and under VPN Settings / Routing select "No" for "Should client Internet traffic be routed through the VPN?" If this doesn't resolve your issue, please create a new post with specific information about how you've set up the server, the client, and exactly what behavior you're experiencing. Include details like: Is this with the Turtle or with your computer? Can you ping by IP but not by hostname? Have your DNS servers changed after connecting to the VPN? Have you run the client in debug mode to get more information about the problem? What client are you using, and on what OS? The reason for creating a new post is because your problem is unique to you. We don't want a 400-page long thread about OpenVPN that answers 26 different questions. The reason for including details is because without them, we can only guess, and when we get into guessing, the quality of support drops rapidly. /m
  3. A correction to my previous post: eth1 (the physical RJ45 port) is wan, not lan, so your config mods should only be: config zone option name 'vpn' list network 'vpn' option input ACCEPT option output ACCEPT option forward REJECT config forwarding option src vpn option dest wan This was hidden in my earlier testing by some other direct iptables commands while I was trying to sort it out. I discovered today after rebooting the turtle that it no longer worked, and logging showed me that traffic was exiting the wan port.
  4. The problem is with the network config for uci. There are no default firewall rules for handling vpn traffic. Without them the turtle won't pass traffic from the vpn interface to the br-lan interface. You can correct this by adding the following to /etc/config/firewall on the turtle. Put it in around line 26, before the lines that start with "config rule": config zone option name 'vpn' list network 'vpn' option input ACCEPT option output ACCEPT option forward REJECT config forwarding option src lan option dest vpn config forwarding option src vpn option dest lan After doing so, run the following: /etc/init.d/network restart This will bounce the interfaces and reset the firewall rules. With these instructions in place, you'll be able to reach the network on the far side of the turtle.
  • Create New...