Community Discussions and Support
Sv: Mercury 4.62 IMAP4 Connection Control

Thank you, Peter.  Yes, a single router would be the most simple solution, which I intend to use when I can find the time.  I now realize that I don't need connection control in Mercury.

Gordon.

 

<P>Thank you, Peter.  Yes, a single router would be the most simple solution, which I intend to use when I can find the time.  I now realize that I don't need connection control in Mercury.</P> <P>Gordon.</P> <P mce_keep="true"> </P>

I have an issue regarding the IMAP4 connection control features of Mercury, though this maybe as much my (lack of) understanding of networking protocols as it may be related to Mercury.

The scenario is this.  For some time I accessed my Mercury server using my mobile phone's E-mail (IMAP4) capability.  So that I could have somewhat better security, I wanted to do some IP source address filtering.  The single router that I was using at the time was a D-Link DI-624, which does provide source address and port filtering in its firewall.  One slight complication is that my wireless service provider uses a range of source IP addresses, and these have to be found by trial and error from the router log, because they are not made publicly available.  All of this went well except that the DI-624 is notoriously prone to re-boots when exposed to wireless interference (from phones, security systems etc) and packet overload.  This results in loss of connectivity and resetting of the router date information back to 2002.  Other than this re-boot problem, the set-up worked well, once I had found out the the correct IP address ranges to allow in.

Eventually, I became tired of the router re-boot problem and purchased another router, a Linksys WRT54GL.  Although this is a much more stable router, it doesn't offer source IP address filtering (at least not with the stock firmware, without using DD-WRT).  To solve this, I cascaded the two routers, the Linksys being closest to the Internet, providing wireless functionality and limiting the traffic exposure of the D-Link, and the D-Link (with wireless turned off) providing the IP address filtering.  The two routers are cascaded (LAN-WAN ports) rather than linked (LAN-LAN) port, so they have separate subnets.  This arrangement works fine and both routers are stable, but I have lost the IP address filtering capabilty to allow my mobile phone access.  Eventually, I plan to put DD-WRT onto the Linksys, but I don't have time to do this at the moment.

Now to where Mercury IMAP4 connection control comes into the picture.  In trying to sort out why I could no longer obtain mail access to Mercury from my phone (which should have been obvious to me, with the cascaded router configuration), I started to look at the connection controls that I had put in place in MercuryI.  What I found was that I could only obtain an IMAP4 connection from the Internet if I allowed address 192.168.1.1.  Now 192.168..1.1 is the address of the Linksys router (closest to the Internet).  The D-Link router, which comes after the Linksys and to which the Mercury server machine is connected, has an address of 192.168.17.1, with all connected machines being on its 192.168.17.0/24 subnet.  The thing that is puzzling me is why Mercury connection control is requiring 192.168.1.1 to be allowed though, when there is another subnet in-between?  This begs another question and that is, if I am using a NAT router with a firewall (and IP address filtering), does MercuryI connection control provide any benefit?

Any help in clarifying these questions for me would be much appreciated.

Thank you

Gordon

<P>I have an issue regarding the IMAP4 connection control features of Mercury, though this maybe as much my (lack of) understanding of networking protocols as it may be related to Mercury.</P> <P>The scenario is this.  For some time I accessed my Mercury server using my mobile phone's E-mail (IMAP4) capability.  So that I could have somewhat better security, I wanted to do some IP source address filtering.  The single router that I was using at the time was a D-Link DI-624, which does provide source address and port filtering in its firewall.  One slight complication is that my wireless service provider uses a range of source IP addresses, and these have to be found by trial and error from the router log, because they are not made publicly available.  All of this went well except that the DI-624 is notoriously prone to re-boots when exposed to wireless interference (from phones, security systems etc) and packet overload.  This results in loss of connectivity and resetting of the router date information back to 2002.  Other than this re-boot problem, the set-up worked well, once I had found out the the correct IP address ranges to allow in.</P> <P>Eventually, I became tired of the router re-boot problem and purchased another router, a Linksys WRT54GL.  Although this is a much more stable router, it doesn't offer source IP address filtering (at least not with the stock firmware, without using DD-WRT).  To solve this, I cascaded the two routers, the Linksys being closest to the Internet, providing wireless functionality and limiting the traffic exposure of the D-Link, and the D-Link (with wireless turned off) providing the IP address filtering.  The two routers are cascaded (LAN-WAN ports) rather than linked (LAN-LAN) port, so they have separate subnets.  This arrangement works fine and both routers are stable, but I have lost the IP address filtering capabilty to allow my mobile phone access.  Eventually, I plan to put DD-WRT onto the Linksys, but I don't have time to do this at the moment.</P> <P>Now to where Mercury IMAP4 connection control comes into the picture.  In trying to sort out why I could no longer obtain mail access to Mercury from my phone (which should have been obvious to me, with the cascaded router configuration), I started to look at the connection controls that I had put in place in MercuryI.  What I found was that I could only obtain an IMAP4 connection from the Internet if I allowed address 192.168.1.1.  Now 192.168..1.1 is the address of the Linksys router (closest to the Internet).  The D-Link router, which comes after the Linksys and to which the Mercury server machine is connected, has an address of 192.168.17.1, with all connected machines being on its 192.168.17.0/24 subnet.  The thing that is puzzling me is why Mercury connection control is requiring 192.168.1.1 to be allowed though, when there is another subnet in-between?  This begs another question and that is, if I am using a NAT router with a firewall (and IP address filtering), does MercuryI connection control provide any benefit?</P> <P>Any help in clarifying these questions for me would be much appreciated.</P> <P>Thank you</P> <P>Gordon</P>

Now to where Mercury IMAP4 connection control comes into the picture. 

In trying to sort out why I could no longer obtain mail access to

Mercury from my phone (which should have been obvious to me, with the

cascaded router configuration), I started to look at the connection

controls that I had put in place in MercuryI.  What I found was that I

could only obtain an IMAP4 connection from the Internet if I allowed

address 192.168.1.1.  Now 192.168..1.1 is the address of the Linksys

router (closest to the Internet).  The D-Link router, which comes after

the Linksys and to which the Mercury server machine is connected, has

an address of 192.168.17.1, with all connected machines being on its

192.168.17.0/24 subnet.  The thing that is puzzling me is why Mercury

connection control is requiring 192.168.1.1 to be allowed though, when

there is another subnet in-between? 

Looks to me like the D-Link router is passing the original connecting IP address to MercuryI.  Since I do not have a D-Link, for the reasons you mentioned previously, I can't be sure but this is quite normal for a router/switch doing NAT.  FWIW, I am using NAT on my LinkSys BEFSR41 and the connecting IP address to my Mercury/32 servers is the original external IP address.  It is connecting from 192.168.1.1 (router) to 192.168.1.2 (Mercury) but I never see this IP address in the Mercury logs.
This begs another question and

that is, if I am using a NAT router with a firewall (and IP address

filtering), does MercuryI connection control provide any benefit?

None that I can see.  With your setup  I suspect all of the connections are coming from 192.168.1.1 so I'm not all that sure what can be done anyway.
Eventually, I plan to put DD-WRT onto the Linksys, but I don't have time to do this at the moment.

I've never tried the DD-WRT firmware.  Let us know how this works out for you.

 

<blockquote>Now to where Mercury IMAP4 connection control comes into the picture.  In trying to sort out why I could no longer obtain mail access to Mercury from my phone (which should have been obvious to me, with the cascaded router configuration), I started to look at the connection controls that I had put in place in MercuryI.  What I found was that I could only obtain an IMAP4 connection from the Internet if I allowed address 192.168.1.1.  Now 192.168..1.1 is the address of the Linksys router (closest to the Internet).  The D-Link router, which comes after the Linksys and to which the Mercury server machine is connected, has an address of 192.168.17.1, with all connected machines being on its 192.168.17.0/24 subnet.  The thing that is puzzling me is why Mercury connection control is requiring 192.168.1.1 to be allowed though, when there is another subnet in-between?  </blockquote>Looks to me like the D-Link router is passing the original connecting IP address to MercuryI.  Since I do not have a D-Link, for the reasons you mentioned previously, I can't be sure but this is quite normal for a router/switch doing NAT.  FWIW, I am using NAT on my LinkSys BEFSR41 and the connecting IP address to my Mercury/32 servers is the original external IP address.  It is connecting from 192.168.1.1 (router) to 192.168.1.2 (Mercury) but I never see this IP address in the Mercury logs. <blockquote>This begs another question and that is, if I am using a NAT router with a firewall (and IP address filtering), does MercuryI connection control provide any benefit?</blockquote>None that I can see.  With your setup  I suspect all of the connections are coming from 192.168.1.1 so I'm not all that sure what can be done anyway. <blockquote> Eventually, I plan to put DD-WRT onto the Linksys, but I don't have time to do this at the moment.</blockquote><p>I've never tried the DD-WRT firmware.  Let us know how this works out for you.</p><p> </p>

Hi Thomas - Thank you for the quick reply.  I think that it reinforces the point that to get effective filtering, I probably have to get away from this cascaded router arrangement so, unless I purchase yet another router, which is stable and which has IP source address filtering built in, I am going to have consider DD-WRT on the Linksys.

As an aside, I originaly bought the Linksys (the Linux model of the WRT54G) with the possiblilty of installing DD-WRT.  The DD-WRT community seems to be doing some great things, potentially allowing fairly major applications to run on the router (especially when adding SD memory to the router).  It's a pity that Mercury doesn't run under Linux, or it might be a candidate :-)

Gordon

<P>Hi Thomas - Thank you for the quick reply.  I think that it reinforces the point that to get effective filtering, I probably have to get away from this cascaded router arrangement so, unless I purchase yet another router, which is stable and which has IP source address filtering built in, I am going to have consider DD-WRT on the Linksys.</P> <P>As an aside, I originaly bought the Linksys (the Linux model of the WRT54G) with the possiblilty of installing DD-WRT.  The DD-WRT community seems to be doing some great things, potentially allowing fairly major applications to run on the router (especially when adding SD memory to the router).  It's a pity that Mercury doesn't run under Linux, or it might be a candidate :-)</P> <P>Gordon</P>

It's a pity that Mercury doesn't run under Linux, or it might be a candidate :-)
Ah but it does.  I'm currently running Mercury/32 on Linux with Wine and it works just fine.  The only problems I've found is the STARTTLS/SSL is not supported in Wine and Linux does not let a normal user use the ports below 1024.  It's not a big deal for me since I'm running a gateway Mercury/32 server on Windows that can route the mail to other ports via SMTP.  The SMTP, IMAP4. POP3, MercuryB are just set to use high ports starting with 8.

Both of these could be worked around if I knew more about Linux but I'm just a nubie there.
<blockquote>It's a pity that Mercury doesn't run under Linux, or it might be a candidate :-)</blockquote>Ah but it does.  I'm currently running Mercury/32 on Linux with Wine and it works just fine.  The only problems I've found is the STARTTLS/SSL is not supported in Wine and Linux does not let a normal user use the ports below 1024.  It's not a big deal for me since I'm running a gateway Mercury/32 server on Windows that can route the mail to other ports via SMTP.  The SMTP, IMAP4. POP3, MercuryB are just set to use high ports starting with 8. Both of these could be worked around if I knew more about Linux but I'm just a nubie there.

Hmmm.  That's interesting.  I did wonder about Wine, though whether this would be practical within the router, I don't know.  I don't see any reason why it wouldn't work, other than the issues that you have come across.  One can add lots of memory to the router using a SD card.  I'll have to dig into this and see if any of the DD-WRT community have tried to use Wine ... a quick Google didn't find anything.

Gordon

<P>Hmmm.  That's interesting.  I did wonder about Wine, though whether this would be practical within the router, I don't know.  I don't see any reason why it wouldn't work, other than the issues that you have come across.  One can add lots of memory to the router using a SD card.  I'll have to dig into this and see if any of the DD-WRT community have tried to use Wine ... a quick Google didn't find anything.</P> <P>Gordon</P>

Gordon, sounds to me like you're trying to solve the intermittent reboot issues, by adding extra cloth - to keep warm... Keep it simple. The only reason for you to have connection control entries in MercuryI is if you suspect intrusion attempts from other machinery behind your NAT-router. If you fear password lookups by wire tap outside your control, f.ex. in a hotel or hotspot, you have to use ssl.

Gordon, sounds to me like you're trying to solve the intermittent reboot issues, by adding extra cloth - to keep warm... Keep it simple. The only reason for you to have connection control entries in MercuryI is if you suspect intrusion attempts from other machinery behind your NAT-router. If you fear password lookups by wire tap outside your control, f.ex. in a hotel or hotspot, you have to use ssl.
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft