While I don't have Pete's certification, I have worked in an environment where payment services is our primary security concern for quite some time now, so my opinion may (or may not be) of some importance. I'm gonna play a little devils advocate here, but please know that I am rooting for you.
That being said, I can see where they would be iffy on allowing you into the internal network, no matter how secure your server is.
If it were my environment, these are the issues I would have with your installation:
1) The server belongs to your group, and they are not paid to maintain it, therefore they have no obligation nor desire to do so. A lot of environment's, particularly of a government nature, have a status quo of not letting anything reside in their environment that is not an asset of theirs because of liability. Your server greatly increases liability because it is not contained in their service level agreements or operating level agreements. Even if you agree to keep the server up to date, and lock it down per their security policy, it still makes them liable. Would I want to have something like that in my environment? No.
(Note that 2 and 3 tie in with the above, but as separate issues needing to be addressed)
2) In order to be acceptable, your installation must decrease their liability to zero by either totally mitigating -or- preferably, eliminating it. Port forwarding does not entirely mitigate the risk because you are still passing traffic on the same collision and broadcast domains where their network resides. In the realm of payment services, this is unacceptable at times. You may be onto something by putting it in the DMZ, but it isn't a total solution in my mind. If it were on a network I managed, it would only be acceptable to me if you were on your own VLAN, segregated from anything on my network. You may want to propose that scenario. Because of the still new and experimental nature of D-Star, there's no way in the world I'd agree to it being anywhere near something on my network.
3) Physical security is also an issue. Because you are not an entity of their organization, you are likely not covered by their insurance. Since you are likely not going to get remote access to this machine, you will need to be physically present to apply any updates, or address problems. This, probably moreso than others, would be my concern. It gives you, a volunteer, total access to my network, which I am accountable and liable for, and that puts customers at risk.
Again, I'm not trying to discourage you, but I wanted to give you insight to the valid questions that they have here that definitely need to be addressed.
My proposed solution would be a separate VLAN on the outer bastion of their firewall. Even the DMZ isn't really an exceptable option to me. That would expose them to no further risk than they already are exposed to. Basically, you're going to have to totally go out of your way to convince them that there is no risk entered into their network.
