jeffrhysjones

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 31 total)
  • Author
    Posts
  • in reply to: nat reflection #45423

    Thanks – but your GUI suggestion doesn’t seem right to me.

    Firstly, I already have NAT enabled on ETH0 in the GUI.
    Secondly, your virtual server suggestion would see all WAN IPs forward port 80 to the web server on the LAN. Although my example only has one IP interface on ETH0 – the live system actually has multiple IPs on the WAN interface. I didn’t mention this before – sorry.

    So it’s not as simple as you think, and certainly not possible via the GUI without POSTROUTING scripts – if it was – this thread would not have been started in the first place – would it? πŸ˜€

    Jeff

    in reply to: nat reflection #45421

    Oh dear – it would help, when asking for help – if I actually type in scripts correctly – it looks like I really cocked stuff up!

    For the sake of completeness (and hopefully clarity) here are the settings and (hopefully) correct resolution:

    Interface IPs on ZS Box:

    ETH0 = WAN Interface 192.168.0.252 (192.168.0.0)
    ETH3 = VLAN A Interface 192.168.254.254 (192.168.254.0/24)
    ETH3 = VLAN B Interface 192.168.253.254 (192.168.253.0/24)

    LAN Server IPs

    Server A, VLAN A = 192.168.254.200
    Server B, VLAN B = 192.168.253.100

    This device is being used only for routing PAT / NAT as we have a transparent firewall device handling firewall stuff.

    The desired functionality is for Server A to have PAT from WAN, but also this should work for servers in the same subnet / VLAN as Server A (VLAN A) – *AND* also for Server B in VLAN B.

    SO. After finally figuring out that I just plain typed up the script totally **wrong**, the following script now works – with no NAT mods required – with just the following TWO lines:


    iptables -t nat -A PREROUTING -d 192.168.0.252 -p tcp --dport 80 -j DNAT --to 192.168.254.200
    iptables -t nat -A POSTROUTING -s 192.168.254.0/24 -p tcp --dport 80 -d 192.168.254.200 -j MASQUERADE

    I am assuming therefore, if I wanted (as per the above example) Server B to be able to connect to Server A but using the PAT on ETH0/WAN interface – I would need to add a third line, for an extra POSTROUTING entry for Server Bs subnet? So the final rule would look like this:


    iptables -t nat -A PREROUTING -d 192.168.0.252 -p tcp --dport 80 -j DNAT --to 192.168.254.200
    iptables -t nat -A POSTROUTING -s 192.168.254.0/24 -p tcp --dport 80 -d 192.168.254.200 -j MASQUERADE
    iptables -t nat -A POSTROUTING -s 192.168.253.0/24 -p tcp --dport 80 -d 192.168.254.200 -j MASQUERADE

    This looks good to you guys?

    The reason why the first PREROUTING line is required, when there is already a Virtual Server entry set up to forward traffic from the WAN to Server A, is that this Virtual Server rule is set only to ETH0 as ‘in’ – which does not work for my case, as I am wanting the ‘in’ interface to also include traffic coming in from ETH3.

    Sure enough, if I remove the interface specific Virtual Server rule and re-add it, this time with the interface set as ‘ANY’ – the ‘NAT Reflection’ works with just the POSTROUTING entries only.

    Jeff

    in reply to: nat reflection #45419

    aha. I am working on this now!

    I have just added the following to the ‘NAT and Virtual Servers Script’ on a test system here:



    iptables -t nat -A PREROUTING -d 192.168.0.252 -p tcp --dport 80 -j DNAT --to 192.168.254.200
    iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.200 -j ACCEPT
    iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -p tcp --dport 80 -d 192.168.0.200 -j MASQUERADE

    WAN IP in my case in this test setup is 192.168.0.252. LAN web server is 192.168.254.200.

    This initially did not work – I did notice that it added the following line to POSTROUTING – this looked right and I thought it *should* work. Alas no.


    MASQUERADE tcp -- * * 192.168.0.0/24 192.168.0.200 tcp dpt:80

    However – if I enable the LAN interface (ETH0) as NAT (move it from left to right in the NAT settings page) – then all of a sudden it works! Hurrah! The additional line added to POSTROUTING when enabling NAT on the LAN interface was:


    MASQUERADE all -- * ETH03 0.0.0.0/0 0.0.0.0/0

    I only had NAT enabled on the WAN interface – that just seemed to work fine and there was never a need to enable NAT on the LAN interfaces as well…..

    I then experimented – thinking perhaps I could remove the first two lines – but alas – this only works with all three lines – even if I already configured a Virtual Server to route traffic from WAN to LAN.

    So now I have this working in my test setup – I just have to take a deep breath and apply it to live. Adding NAT to ETH3 seems like a bit of a blunderbuss method – if someone has an idea of how to achieve a working solution without having to NAT everything on ETH3 -or can spot why this script isn’t working on its own – that would be my preferred solution I think.

    Nearly there with this anyway….

    Jeff

    in reply to: nat reflection #45417

    Hi zevlag!

    Firstly – thanks very much again for your patch for the > 100 virtual servers – I don’t know what we would have done without it! Works a treat!

    We would also like a solution for this PAT / VS issue. I think it’s the same one – basically, we have an email server configured on a VS on a public IP which NATs through to a private VLAN – lets call it VLANA).

    The email server can send and receive email fine to all users / servers on the WAN interface (outside).

    However we have servers inside the firewall – say on VLANB that also need to be able to send email to this server – alas – it’s not possible.

    I have had to do a horrible ‘internal DNS / email domain’ fix which isn’t perfect.

    So I would really like to be able to achieve this ‘NAT Reflection’ functionality in our setup – as one person pointed out on this list – it works great in PFSense.

    I only need this on one or two VS’s so if it’s a line in a script somewhere that would also work.

    Cheers – hope you are well!

    Jeff

    I needed to do a:

    patch -p1 -d / < /Database/patches/[name].patch

    That worked.

    BIG THANKS to Josh (zevlag) for his help on this pretty serious bug. Anyone that creates more than 99 Virtual Servers with the current release will merrily add virtual servers, and think they are all good – until they go to delete them – they will not show up in the list. Worse, if you reboot- they all go.

    The supplied patch has totally fixed the problem and it’s about time ZS was fixed!!!

    Anyway – I hope this thread helps someone before it’s too late.. I can’t be the only person out there with more than 99+ Virtual Server entries…

    Can I!?

    Cheers,

    Jeff

    Hi Josh,

    Can U believe it – it’s taken me all this time to getting round to patching this ZS box!?!

    I came back to this thread today and downloaded the patch file you created (thanks again!).

    However – now I’m sort of stuck as you didn’t tell me how to actually patch the box.

    I have tried uploading the .patch file you created to /Database and running:

    patch -p0 < /Database/[nameofpatchfile].patch but it just errors out.

    I’ve also had a go at manually editing the scripts – which does work – however when you reboot the box, the issue returns.

    Any help – much appreciated.

    Cheers,

    J

    in reply to: Some Virtual Servers hidden from listing – how to delete? #49625

    Hi Josh,

    I was just wondering about this today! I didn’t get an email notification from the forum so just assumed you were a bit busy!

    I’m working away from the office until Friday – I will get on to this then and let you know OK?

    Thanks again for your help on this!

    Lifesaver!

    Jeff

    in reply to: Some Virtual Servers hidden from listing – how to delete? #49621

    To get me out of a hole on this one – can anyone help me with some grep scripting (or whatever) which might be able to help me compare rules saved in the Virtual Server database, with those running in iptables. Basically, to show me the missing DB rules.

    Then I could add the currently non-persistant rules to the NAT startup script.

    Cheers,

    Jeff

    in reply to: Some Virtual Servers hidden from listing – how to delete? #49620

    OK I have done more testing – and YIKES – all my fears have been confirmed. More than 100 virtual server and you are in trouble.

    1) THE SETUP:

    Clean Zeroshell box – 1.0 beta 11

    2) Type in 100 Virtual Servers (took a while…)

    I add 100 virtual servers to the box. These go in fine. 100 folders showing in /Database.

    3) However – after you add in VS 101, this rule does NOT show up in the list of virtual server entries.

    4) However, entries after 100 that you add DO get added to iptables rules – so you THINK it’s all going to be fine

    5) However on the next reboot – UH-OH – all the rules that are not listed, Gone. Wiped!

    6) Now, if you delete 5 of the 100 rules – and then you add one more – this is OK – this rule now shows up.

    7) The next thing is a bit more confusing. If you then add an additional rule, this rule now over writes that rule you just put in.

    8) Just like before – it all works, so you think you are OK. But after the next reboot – that last rule – it won’t be there.

    So basically – in short after you add your 100th VS – horrible things happen to your ZS box.

    Beware!

    J

    in reply to: Some Virtual Servers hidden from listing – how to delete? #49619

    Well that’s the point – I’m not removing these virtual server rules from /Database – ZeroShell is removing them for me as I add new rules!

    I need to do more testing on this – but I seriously can’t have a firewall that appears to ‘ramdomly’ remove rules as I add new ones.

    That’s just crazy…

    J

    in reply to: Some Virtual Servers hidden from listing – how to delete? #49617

    @ zevlag – thanks for this! I was a bit desperate to fix this so I deleted the offending line from PREROUTING in iptables as ppalias (thanks also!) suggested.

    Not sure if doing this will retain settings after rebooting the FW.

    Actually – now I’m starting to worry that – as these lines do not show in the list of Virtual Servers, but only in the iptables – will they still exist after a box reboot?

    Doing an ‘ls’ in that directory gives me:

    root@zeroshell PAT> ls
    03 09 14 19 33 41 44 59 62 69 73 81 84 87 90 93 97
    04 100 15 22 38 42 55 60 63 70 74 82 85 88 91 94 98
    07 13 16 23 39 43 58 61 64 71 75 83 86 89 92 96 99

    The 100 directory seems to be the latest rule that I added.

    Now here is what is interesting. When I add another rule via the virtual server page – this directory is 03, and what was on 03 seems to get deleted.

    So what I am saying is that I have folders missing from this PAT folder seemingly being deleted by ZS as I have been adding new Virtual Servers. There are 51 PAT VS folders – but there are 74 NAT rules showing in PREROUTING.

    If I reboot this box, will I end up with only 51 NAT rules?

    Am I sitting on a timebomb?

    This is seriously scary stuff…

    J

    in reply to: Some Virtual Servers hidden from listing – how to delete? #49614

    Just thought I would go through and remove any Virtual Servers from the list in the hope that some others would then appear as I deleted them.

    They didn’t πŸ™

    So I now have a list of 50 showing in the ‘list virtual servers’ page – but I have more that I have added to the configuration – just they are not showing up. There are some duplicates in there as well – as in the past I have added servers – not seen them appear in the list – and added them again!

    All the time, Virtual Servers were being added, just not displayed.

    How can I clean this up!?

    Help!

    πŸ˜₯

    J

    in reply to: VERY HIGH (up to 180%) processor load #48482

    Do we know if Zeroshell can use the crypto acceleration features of the AMD Geode LX yet?

    This is the combo used in the Soekris net5501 box, I would like to run openVPN in the future, but now I have seen this, I’m worried about it chewing up all my CPU.

    There was some talk of a kernel update earlier this year that would allow for this – I think!?

    Jeff

    OK I have recreated a ZS ‘simple basic’ setup:

    INPUT – DEFAULT: DENY

    ACCEPT tcp opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp dpt:443

    OUTPUT – DEFAULT: DENY

    ACCEPT tcp opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp spt:443

    FORWARD – DEFAULT: DENY

    (No rules)

    So (as far as I am aware!) this is a simple setup where you allow management of the box from any interface via HTTPS, and everything else is blocked, even if you have added in a Virtual Server.

    In my example here, the external interface is ETH0 – network 192.168.0.0

    I now want to add a virtual server, the physical (REAL) server for which is on ETH1 – network 192.168.254.0. I want to be able to remote desktop in to this server from ETH0.

    So first of all I create a virtual server:

    INTERFACE/IP: ETH0 / 192.168.0.252
    PROTOCOL: TCP
    LOCAL PORT: 3389
    REAL SERVER: 192.168.254.2:3389

    Great this is added – however, I can not get through. The reason for this is that I have still to create a rule through the firewall for this Virtual Server to work. If I had 100 Virtual Servers, then I need to create 100 rules. Actually, I have to create 200 rules, as you will see.

    So rather than to mess up FORWARD with all my virtual server rules, I create a new chain called vserver.

    Next I make sure that all forwarding traffic goes to this (I’m not using this box for anything else)

    FORWARD – DEFAULT: DENY

    vserver all opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0

    This sends everything to chain vserver.

    Now I create my rule in vserver:

    VSERVER

    ACCEPT tcp opt — in * out * 0.0.0.0/0 -> 192.168.254.2 state NEW,RELATED,ESTABLISHED tcp dpt:3389

    I do this… try to connect, and nothing. I use a packet sniffer, and notice that for some reason packets are not coming back through the firewall, even though, as we are using STATE, they should be related.

    The only way I can get remote desktop to work, is to create a second rule, allowing traffic from the server out again:

    ACCEPT tcp opt — in * out * 192.168.254.2 -> 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp spt:3389

    So my final vserver chain now looks like this:

    VSERVER

    ACCEPT tcp opt — in * out * 0.0.0.0/0 -> 192.168.254.2 state NEW,RELATED,ESTABLISHED tcp dpt:3389

    ACCEPT tcp opt — in * out * 192.168.254.2 -> 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp spt:3389

    Thus – this example shows that when you create a vserver rule, not only do you also have to create an additional rule for it in the firewall, but you actually have to add TWO.

    For people with 100’s of virtual servers (in a hosting environment) this is a huge resource drain, and makes life extremely complicated.

    We are now hoping to create a script which will ‘read’ vserver rules and create both sets of firewall rules for them in a special chain called vserver, as in the above example. This will save a huge amount of time/work.

    Jeff

    Fantastic – by the way – with regards to the bounty – is Paypal OK? Plus – preferred currency?

    Also I think it’s right that I send Fulvio a little something also as perhaps he might want to look over this and that’s his time if he chooses to do that. If not, well he deserves it anyway!

    I will get the output stuff. I will set up a clean system again just to make sure I’ve not screwed something up on one box.

    Cheers,

    Jeff

Viewing 15 posts - 1 through 15 (of 31 total)