I posted a question a couple of weeks ago about retrieving SMTP mail from an
ISP using a Windows NT server. Thanks for the replies. For those that are
interested, and before I ask another question, the ISP needs to allocate a
fixed IP address to the WAN port of the ISDN router. The router then has to
have 'Port Address Transalation' so that the ISP can connect to port 25 of
the router WAN address, and this is then translated to port 25 of your SMTP
Exchange server. Basically, when you deliver outgoing mail to the ISP using
SMTP, you need to send an ETRN command that requests the SMTP server at the
ISP to send your incoming mail to your server. Sounds complicated, but I
thought it may be of interest/use.
However, we have two ISPs, one for the email, and a 'free line' for the
Internet. If I configure the Port Address Translation so that the email can
work, the call to the Internet ISP doesn't work properly. I'm thinking
about maybe adding a second router and splitting the Internet/Email, but I'm
not sure how to route Internet through one router and email through the
other. The default gateway is set to the existing router. I've tried
configuring the router so that traffic destined for the Mail host brings up
one 'autocall', and the Internet traffic brings up the free autocall, but as
I say, it seems the the NAT for the fixed WAN IP address is causing
problems.
Thanks again
David Nash
I wish you wouldn't:
1. Assume that I've read your un-referenced previous posting.
2. Refuse to disclose any numeric information such as the make and
model of your firewall.
3. Not post any diagnostic output such as your router table.
You cannot dial two ISP's and still have a fixed default route. That
will not work. When you dial ISP#1 for email, the default route will
need to point to that ISP's gateway. When you hangup and dial ISP#2
for cruising the internet, the default route will need to move to that
ISP's gateway. Try:
route delete default xxx.xxx.xxx.xxx
route add default xxx.xxx.xxx.xxx
No need to reboot. Check the results with:
netstat -rn
I would look into staying connected with ISP#2 and just picking up
your email via SMTP from ISP#1. I do this all the time. I have
something like 8ea email accounts, all of which I can pickup from any
ISP. How you connect to the internet is different from what services
you use once connected unless you're dealing with a proxy server).
Some ISDN firewalls allow for multiple ISP's and include provisions
for moving the default route. Just about any NAT firewall will do
this. Just point your servers default route and DNS server to your
unspecified router/firewall and let it do all the dirty work.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.LearnByDestroying.com WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
Yes, but there's no particular reason that he needs two dialups- I've set up
plenty of situations like this where the mail isp is different from the
internet access isp- especially since it's smtp, there should be absolutely
no reason he can't do this.
He needs an inbound nat translation (who knows what they might call it on the
router, but it doesn't matter- port 25 on some public address redirects to
some internal address). He sends the etrn out over the internet link and it
responds.. no issue.
Somethings set up wrong somewhere..
--
Tony Lawrence (to...@aplawrence.com)
SCO/Linux articles, help, book reviews, tests,
job listings and more : http://www.pcunix.com
Ours is different, I think; if I understand it, we have a class C
LAN which is connected to the Internet by an ISDN router (all addresses
issued by the ISP), and any server that we put on that network
(usually dual-homed) is on the Internet. So that's where our mail
server is - we did have to tell the ISP which of our addresses we
would use for that. Whereas, if I read right, your ISDN router is
using _one_ ISP-provided address, which addresses the ISDN side of the
router, and translating each possible port number to an appropriate
port on a server on your LAN.
> However, we have two ISPs, one for the email, and a 'free line' for
> the Internet. If I configure the Port Address Translation so that
> the email can work, the call to the Internet ISP doesn't work
> properly. I'm thinking about maybe adding a second router and
> splitting the Internet/Email, but I'm not sure how to route
> Internet through one router and email through the other.
> The default gateway is set to the existing router. I've tried
> configuring the router so that traffic destined for the Mail host
> brings up one 'autocall', and the Internet traffic brings up the
> free autocall, but as I say, it seems the the NAT for the fixed
> WAN IP address is causing problems.
ISDN is designed to be shared, so certainly you should be able to
use one router just to get to specified hosts on your e-mail provider
and another router to get to the 'free line'. In this case you'd
have default route to the second router, for the free line,
and you'd set an explicit route to router one for the e-mail provider's
hosts.
(If the 'free line' provider provides e-mail, you might be able to
send it out in that direction with your e-mail provider's addresses
on it, but then again you might not - and anyway, if your configuration's
like ours in another detail, you don't get e-mail _from_ them by ISDN
until you place a call _to_ them by ISDN. Ours doesn't call us,
we call them.)
A detail of NAT that I don't appreciate is whether the ISP's e-mail
will appear, from your server's point of view, to be coming from your
e-mail ISP's server or directly from your router. This is relevant
because SCO OpenServer, at least, and with MMDF at least, and for me
at least, has been fussy about which servers it does and doesn't
accept SMTP e-mail from. (This is reasonable, since the alternative
is an open relay which can be used for spam.)
Our router is a fairly basic model, but it can place calls to
multiple remote ISDN devices at once, so I don't see why yours
shouldn't do this. And you say that it does, _until_ you set
the router to accept e-mail from _that_ ISP and pass it on to
your mail server. Then you can't use your Internet connection.
That appears to be a defect in the router, and not a deficiency in
your understanding of the network. Perhaps a defect of design, in
which case you might as well buy another one - or buy a different one.
One suggestion, though: perhaps your router is unhappy that
one autocall is supposed to connect you to the e-mail ISP,
whereas another autocall is supposed to connect you to the
entire Internet, _including_ the e-mail ISP's servers on the
Net. In that case, perhaps you could get around that by
setting the router to use the free line to connect you,
not to the whole Internet, but only to the 'free line'
provider's local network - which should include a proxy
server. You would then set Internet applications to use
the proxy server to get to the rest of the Internet. If
the router doesn't know that that connection goes to the
whole Internet then it may not get confused ;-)
You of course are using a "private" network address space as
recommended by RFC 1918 for your own network.
If one of the connections is only used to talk to a particular host, then he
should be able to leave his default route set to the internet connection,
and simply define the route(s) for the mail host or net explicitly.
Seems like it should be about the same as a few sites I have where there is
a unix box with more than one nic. one nic is on a local lan and the default
gateway to the internet is on this lan. the other nic is on a private
frame-relay wan that does not have an internet gateway. the default route
stays pointed at the nat router on the local lan, and there are a few
explicit route add commands in rc to set up the other nic and other network.
If a client asks for a machine in the wan, the default route does not come
into play. If it ever does, that just means I need to add more explicit
routes or fix wrong ones for the wan.
In this particular case however, the machines on the wan are all accessed by
IP, or at least, they can all be defined in /etc/hosts with no problem. If I
needed to use dns on the private wan in order to get to machines on the
private wan, I don't know how I could maintain seamless browsing on both
networks. right now I happen to be lucky enough that I can just leave the
resolv.conf with internet nameservers in it all the time.
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
(...)
>> You cannot dial two ISP's and still have a fixed default route. That
>> will not work. When you dial ISP#1 for email, the default route will
>> need to point to that ISP's gateway. When you hangup and dial ISP#2
>> for cruising the internet, the default route will need to move to that
>> ISP's gateway. Try:
>> route delete default xxx.xxx.xxx.xxx
>> route add default xxx.xxx.xxx.xxx
>> No need to reboot. Check the results with:
>> netstat -rn
>
>If one of the connections is only used to talk to a particular host, then he
>should be able to leave his default route set to the internet connection,
>and simply define the route(s) for the mail host or net explicitly.
That makes sense if both connections were up simultaneously (which is
not the case). If the free email ISP demand that you connect via
their dialup to get free email, then a static route to their mail
server would be required. However, as there is only one connection at
a time available, it's probably overkill.
>Seems like it should be about the same as a few sites I have where there is
>a unix box with more than one nic. one nic is on a local lan and the default
>gateway to the internet is on this lan. the other nic is on a private
>frame-relay wan that does not have an internet gateway.
Yep, where both the internet gateway and the framis-relay were up at
the same time. Again, that's not really applicable when only one
connection at a time is available (as in dialup). The default route
has to point to the active connection.
why? If you know you are not going to random internet hosts, but only to
hosts which fall within the static route?
(at least while the email-only connection is up anyways)
In any event, has anybody told him yet that he can put commands in
/etc/ppphook.sh that add-remove routes and manipulate pre-made copies of
/etc/hosts and /etc/resolv.conf so that these files that I'm saying should
be able to go without being changed all the time, can also be changed
automatically whenever pppattach and ifdown ppp0 is run ?
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
>
>
>> Yep, where both the internet gateway and the framis-relay were up at
>> the same time. Again, that's not really applicable when only one
>> connection at a time is available (as in dialup). The default route
>> has to point to the active connection.
>
>why? If you know you are not going to random internet hosts, but only to
>hosts which fall within the static route?
>(at least while the email-only connection is up anyways)
Oh, I see. If you only need to connect to a single (SMTP) host,
there's no need for a default route to the rest of the interknot.
However, I'm assuming that free email also means free advertising.
These may be coming form various parts of the internet and may require
a route to them. The SMTP mail server may be part of a pool, where:
mail.whatever.com
might resolve into a variety of IP addresses in some kind of load
balancing scheme. Although one could configure the connection to a
single IP address, if resolving the name of the mail server requires
pointing to a different IP for DNS server, it won't work because the
default route is pointing to the other ISP's gateway, which is
currently not available. I can think of a few other issues caused by
the lack of a functional default route to screw things up. In my
never humble opinion, unless EVERYTHING is handled by a single IP
address, there needs to be a way to get to other IP's.
>In any event, has anybody told him yet that he can put commands in
>/etc/ppphook.sh that add-remove routes and manipulate pre-made copies of
>/etc/hosts and /etc/resolv.conf so that these files that I'm saying should
>be able to go without being changed all the time, can also be changed
>automatically whenever pppattach and ifdown ppp0 is run ?
I usually add them to whatever script calls the dialer for a specific
ISP. Putting it in /etc/ppphook.sh will work, but will need to be
stuffed full of conditionals for each ISP. Methinks seperate files
for seperate ISP's would be better.
> >In any event, has anybody told him yet that he can put commands in
> >/etc/ppphook.sh that add-remove routes and manipulate pre-made copies of
> >/etc/hosts and /etc/resolv.conf so that these files that I'm saying
should
> >be able to go without being changed all the time, can also be changed
> >automatically whenever pppattach and ifdown ppp0 is run ?
>
> I usually add them to whatever script calls the dialer for a specific
> ISP. Putting it in /etc/ppphook.sh will work, but will need to be
> stuffed full of conditionals for each ISP. Methinks seperate files
> for seperate ISP's would be better.
Yeah me too, but then we are into describing how to make a ppp up/down
script modeled after quickppp found on tony lawrences site. not trivial imo.
It seems putting the commands in such a start/stop script makes them happen
faster too. ppphook seems to take an inexplicably long time to be called
after the connection is up.
actually, taking another look at ppphook just now... it's trivial to do the
default route from there, it's just
route add default $6
well, as long as you are only using ppp to initiate connections to the
internet. If you had a net connection, but wanted to start a ppp connection
to a remote office for some non-internet task, this would screw up the
default route, which should have been left alone in that case.
But the nameservers would be completely impractical from there unless you
are lucky enough to be able to get away with just setting the nameserver to
the ip of the other end of the ppp link. really need an up/down script for
each isp otherwise. it's easy from there.