Posts by Brutis

    I had a very basic install too but after so many problems appearing after upgrading OMV (with no plugins) I did a fresh install.
    Slow booting, couldn't update, notification GUI errors and errors popping up on various other GUI pages.


    The install and reconfigure was only about 1/10th of the time I had spent trying to fix it.
    My advice.... avoid the pain of upgrading and just fresh install, then update to 3.0.46 before you configure anything.

    I would suggest (for any future orders) asking the reseller if the battery is included. I've noticed resellers are using stock pictures which show a battery but sometimes further down in the description they will say no battery. The one's that don't say, which I've asked so far, have said no battery. I gave up in the end and ordered some batteries from another reseller, strangely it wasn't a problem to post them.


    New Zealand has regulations for posting Lithium batteries. https://www.nzpost.co.nz/perso…ohibited-restricted-items


    The ebay supplier (in the above post) has confirmed that the battery is no-longer included (Yes, even though one is shown in the photo's)


    Actually I don't think any of them include the battery now due to postal regulations for lithium batteries.

    I ended up following the "howto" guides on the ipredator site and it is working. No leaking between eth0 & tun0 whether the vpn is up or down. DHT and Trackers are working. Ipredator also recommends a random peer port which when checked shows as being Open.
    There are a lot more firewall rules but they are easy to manage with the ferm package. Firewall rules for UDP ports 80, 1337 and 6969 need to be added to ferm.conf


    So once again thanks for all your help.

    I followed the steps but in my case it wasn't reading the hardware clock on boot
    i2cdetect -y 1 gave 68
    When I checked in etc/rcS.d, for some reason the hwclock.sh file had a kxx prefix so I deleted that file
    Once again I ran the commands update-rc.d -f hwclock.sh remove & update-rc.d hwclock.sh defaults
    Now the hardware clock is working on boot.

    It is probably my mobile provider because the results are different if I use nmap on my real ip. If I use internet based scanners like the one at grc.com then it shows all ports as stealth. I'll ask my friend who runs the website if he can scan the vpn when it is up and see what he gets.


    Just wanted to say again that I really appreciate all your help.


    btw..I was surprised at the guide on the ipredator site. They gave instructions for setting up the vpn but with no warnings for setting up a firewall. I suppose linux uses know to do that by default.

    Sorry for taking so long to reply. My poor old laptop failed on boot with a puff of smoke from under the keyboard so just spent the last 5 hours fixing that. Hard to believe a 0.1uF capacitor took out 2 mosfets and a track on the pcb :-(


    My tests weren't at all helpful using my iphone tethered to the laptop.
    nmap was showing a lot of ports as open no matter what ip address I scanned, real, vpn or a friends website. I even disconnected my router from the phone line and my static ip address was still showing all the same ports as open so I think the service providers maybe running some sort of port scan denial service.

    Using nmap -sT -sU -p U:51413,T:51413 -v 46.246.41.211 gives

    Code
    PORT STATE SERVICE
    51413/tcp filtered unknown
    51413/udp open|filtered unknown


    What is a little strange is every udp port I try is open nmap -sT -sU -p U:80,123,22,51413,T:80,123,22,51413 -v 46.246.41.211

    Thanks again for all your help. It is certainly interesting for me and I hope you are ok spending the time.
    I just wanted to say that if it is easier, all I really need to achieve is having transmission go through the vpn but if the vpn should fail then any connections are blocked.
    Only openmediavault, openvpn and transmission will be running on this Raspberry pi2.

    Stopped transmission and openvpn services
    iptables -F
    ip route flush table vpn
    ip route flush cache
    Started transmission and 51413 was open. Trackers and DHT working through my real IP


    Removed script and route-noexec from .conf
    Started openvpn and transmission. Port 51413 was open. Trackers and DHT working through my vpn IP


    Reinstated script and route-noexec from .conf
    Started openvpn and transmission. Port 51413 was closed. Trackers and DHT not working through my vpn IP


    Restarted transmission and port 51413 was closed but Trackers and DHT working
    Tried this a number of times and whether the Trackers are working is a bit intermittent.

    I'm a little confused.
    If 176.9.62.182:64403 is sending data to 192.168.0.12:51413 is that connecting via my real ip address? because if tun0 is down then the default gateway is used, is that right? If the default gateway is used then 176.9.62.182 is seeing my real ip address so a Input rule won't stop that.

    I stopped and restarted openvpn during a torrent download then checked tun0. I was surprised to see the lines with connections to 192.168.0.12 is that normal?


    the lines with 192.168.0.12 eventually disappeared