Fred, indeed I thought so too.
The DMZ has stated here doesn't exactly describe my situation though. In most cases, the DMZ is a subnet of servers / devices where their uplink is through m0n0.
However, in my case, I'm attempting to bridge to another network on the DMZ interface. In terms of use scenarios, you can say that I'm actually trying to connect to two WAN interfaces, one default WAN to the internet, and another to my client's network.
As for why I thought that the routing is the problem, I'm basing it on this tracepath output that I'm getting:
feiciet@lespaul:~$ tracepath -n 10.198.250.151
1: 192.168.1.50 0.131ms pmtu 1500
1: 10.198.250.151 0.393ms reached
1: 10.198.250.151 0.383ms reached
Resume: pmtu 1500 hops 1 back 64
You will see when I tracepath to my DMZ interface, the path goes directly to that interface IP.
However, when I try to trace to an IP that is behind the DMZ:
feicipet@lespaul:~$ tracepath -n 10.198.0.1
1: 192.168.1.50 0.117ms pmtu 1500
1: 192.168.1.1 0.391ms
1: 192.168.1.1 0.377ms
2: no reply
3: no reply
10.198.0.1 is the next hop from 10.198.250.151, i.e. 10.198.250.151's gateway. If you see the tracepath output, it's like 192.168.1.1 doesn't know where to route the request after itself.
Sorry, really running out of ideas here. Any clues?
Thanks,
Wong
I don't see the need for any static routes here. You just need the correct firewall rules to allow the desired traffic between LAN and DMZ and DMZ and LAN.
Have you looked at the m0n0wall Handbook section on DMZ yet?
http://doc.m0n0.ch/handbook-single/#id11642778