General Questions

Hello,

My network configuration is as follows:

Code:

Internet
   |
DSL Modem (192.168.6.1)
                |
***************************************************************************               
*    (eth0:192.168.6.2) proxy (192.168.7.1:vmnet1)                        *
*                                   |                                     *
*                             (192.168.7.2) m0n0wall VM (192.168.1.254)   *
*                                                           |             *
*                       ssh   (192.168.1.247:eth1)----------+             *
***************************************************************************
                                                            |
                            win2003 server (192.168.1.1) ---+
                                 client 1 (192.168.1.10) ---+
                                 client 2 (192.168.1.11) ---+
                                            .            ---+
                                            .            ---+
                                            .            ---+
                              client 230 (192.168.1.240) ---+

I'm using m0n0wall 1.3b15 running a virtual machine (VMware server 2.0). The VMware appliance was downloaded from the m0n0wall site: generic-pc-1.3b15-vm.zip. m0n0wall is used for a captive portal to limit Internet usage by staff.

The physical machine has two interfaces. The first (eth0) is connected to a dsl modem, the second (eth1) is configured in bridge mode. It has an IP in the same range of the LAN but the firewall on this machine drops all packets apart from SSH. The LAN interface in m0n0wall is connected to eth1 with another IP in the LAN range.

The Win2003 server is required to allow all clients to authenticate against the domain and access exchange and their shared folders. It also provides DNS and DHCP to clients.

The default gateway on all machines is set to the m0n0wall machine and the m0n0wall DNS was added as a forwarder to the win2003 DNS. All of this works fantastic.

Two of the client stations have to communicate with a financial institution to configure direct debit, perform credit card transactions, make payments etc. For this the financial institution has provided an application. This application uses a dial up modem to dial in and then interact over this connection. Since we installed m0n0wall this stopped working.

On the client machines it appears that the machine is trying to route all the data through the LAN interface instead of through the modem.

When m0n0wall is removed from the configuration then the banking software starts working again.

Is there a way to prevent this from happening?

I noticed a 192.168.1.X range in the mix, a lot of DSL modems use the 192.168.1.X range by default, so I wanted to clarify that you manually override the DSL modem settings to 192.168.6.X ?

The DSL modem has been manually configured as 192.168.6.1. It is physically on a different network segment than the rest of the network.

The problem is not Internet access or LAN access for that matter under normal operation.

The problem occurs, and only occurs, when a client dial up with a standard POTS dial up modem to the bank. At that point the client (and only the client) cannot get any data going to the Internet, LAN or the bank. It appears at that point that the Windows XP PC is trying to route all packets over the LAN connection although the route for the remote server is specified over the POTS connection. The POTS modem receives an IP address in starting with 172.x.x.x which is on another network segment. The connection only pushes down one route (not a default gateway) to their system.

When I take m0n0wall out of the picture, i.e. the default gateway on the LAN becomes the DSL modem then everything works. It therefore appears that m0n0wall is pushing some setting to the client to force all data over the LAN connection through m0n0wall.

Results of what I have done:
- Use m0n0wall as default gateway : No data transferred when client connects to bank with POTS modem
- Take server out of picture and use DSL modem as default gateway: Everything works
- Take m0n0wall out of the picture, use the proxy server behind m0n0wall as default gateway: Everything works

The DSL modem has been manually configured as 192.168.6.1. It is physically on a different network segment than the rest of the network.

The problem is not Internet access or LAN access for that matter under normal operation.

The problem occurs, and only occurs, when a client dial up with a standard POTS dial up modem to the bank. At that point the client (and only the client) cannot get any data going to the Internet, LAN or the bank. It appears at that point that the Windows XP PC is trying to route all packets over the LAN connection although the route for the remote server is specified over the POTS connection. The POTS modem receives an IP address in starting with 172.x.x.x which is on another network segment. The connection only pushes down one route (not a default gateway) to their system.

When I take m0n0wall out of the picture, i.e. the default gateway on the LAN becomes the DSL modem then everything works. It therefore appears that m0n0wall is pushing some setting to the client to force all data over the LAN connection through m0n0wall.

Results of what I have done:
- Use m0n0wall as default gateway : No data transferred when client connects to bank with POTS modem
- Take server out of picture and use DSL modem as default gateway: Everything works
- Take m0n0wall out of the picture, use the proxy server behind m0n0wall as default gateway: Everything works

Oh yeah, that's actually a windows issue you have then. I understand now because I know exactly what the problem is, I've encountered this before as well myself.  To override the LAN gateway, you need to set the "Internet Options" in the control panel.  When you get to that window, look for "connections" tab, and you'll see the dial adapters. See the connection settings to "Dial whenever a network connection is not present" and save the settings, give it another try.

By default in XP anyway, the dial up connection should always supersede the LAN instead of the other way around. If you manually do a dial up connection (which it sounds like the software does) hopefully that will kick windows around to using the dial up gateway rather than the LAN gateway.

Let me know if that helps, I can think of a few other things you can try.

Thanks knightmb.


The setting doesn't actually make sense since the user will always be connected to the LAN. I will give it a shot though.

Unfortunately I will only be able to get to those PCs after month end (next Tuesday/Wednesday - the financial people got a bit upset after we "broke" their computers so they want to finish the month end first.

Thanks knightmb.


The setting doesn't actually make sense since the user will always be connected to the LAN. I will give it a shot though.

Unfortunately I will only be able to get to those PCs after month end (next Tuesday/Wednesday - the financial people got a bit upset after we "broke" their computers so they want to finish the month end first.

It doesn't make any sense to me either, just part of windows weirdness.  One thing to add to your checklist then, make sure they don't have the gateway manually coded into their TCP/IP settings since that will often override the dial-up adapter too.  By default, windows *usually* uses the gateway of the last connected device. I've had issues on my laptop that runs XP where it's connected to the LAN, I turn on the WLAN and can't get Internet through the WLAN because it's still trying to gateway through the LAN.

If you still have issues, depending on how their software is setup, you could write a batch file that starts the financial program that they use. Put a command in the batch file before the program starts to release the IP of the LAN, so that it's certain their dial-up software gateway will take priority. Then have it renew the LAN IP after they exit the financial software.  If the LAN is important for file sharing or printers though this would not work, but it's another idea at least.